[Resolved] What causes the IOS button click behaviour to need a double tap sometimes

[Frank]

Hi,

In the process of optimising the user experience, the issue occurred in my current project that the sticky ‘wc-sticky-cart-panel’ or ‘add-to-cart-panel’ sometimes needs to get a double tap or even triple tap for it to actually respond on IOS devices. I was wondering where the nature of this behaviour comes from. Could it be because the element has a :hover styling attached to it, so it first triggers that? (Testing this on variable products)

On a small side note, after pressing the select options button it sometimes doesn’t disappear as well after scrolling back up. It seems as if the ‘show-sticky-add-to-cart’ class isn’t toggled consistently.

[David]

Hi there,

generally that occurs because scripts are being deferred ( cache/optimization plugins ) or another script is applying eventListeners thats interfering with those scripts.

If you can share a link to the site i can take a look for any obvious issues.

[Frank]

Thank you for the fast reply. Absolutely.

[Tom]

Hi Frank,

I wasn’t able to take a look while the site was open.

Just to confirm, is it the button in the panel that isn’t responding, or is the panel as a whole?

[Frank]

Hi Tom, No problem.

It’s specifically the button when applying the touch. I think it’s somewhat generalised as the IOS double tap issue. Judging from the css behaviour it feels like it gets stuck in the hover mode on the first touch. Something like, the first tap focusses the element and the second one actually triggers the event if I had to guess what’s happening.

– For the side note –

After the button press triggers and the page scrolls back up to the variations-form, the full panel sometimes remains visible at the bottom of the screen until the screen manually gets scrolled, then properly disappears.

Thanks so far.

[Tom]

Can we try a quick test?

Can you:

1. Add a new test page.
2. Add a regular button block or a link with the class button
3. Try tapping the button on iOS – does the same thing happen?

I’m trying to determine if this is specific to the WooCommerce buttons or if it’s just buttons (and their hover styles) in general.

[Frank]

I’ve updated the home page and added a few buttons. Kept them there for you to check, added the class ‘button’. Was clickable directly. Then I added a woocommerce class to the container around the button. Was still clickable directly.

After inspecting the woocommerce pages I noticed the buttons were styled using an a-tag that had the class ‘button’ and ‘button alt’. I’ve added both buttons on the home page as well for you to inspect.

Also added one using the button-tag.

The panel itself though uses a button-tag type ‘submit’ maybe this comes in to play? It relies on jquery by default to commit to the scrolling action?

I can tell the woocommerce css styling is applied on all though.

[Frank]

It seems whenever the footer part of the website is inside the viewport, the double tap behaviour starts becoming more apparent. You can tell the hover status also toggles when it starts bugging. Or when you tap it when the page is still scrolling. Maybe it’s because the panel has it’s own animation attached to it?

On the frontpage the button touchend seems to consistently trigger the correct response.

[Tom]

Interesting – thanks for testing!

It could be the javascript. We can test it a bit here if you’re willing to edit a file?

If so, try this:

1. Open wp-content/plugins/gp-premium/woocommerce/functions/js/woocommerce.min.js
2. Search for: ".go-to-variables").on("click"
3. Replace it with: ".go-to-variables").on("click touchend"

Any difference?

[Frank]

Doesn’t seem to change anything, it just feels like it first gets into ‘focus’ as if the div itself (or the div around the button) gets the attention and then it starts registering the actual touchend event on the second press which triggers the javascript. Maybe I’ll just have to accept it as it is.

[Tom]

Really strange, I can’t think of what could be happening. I don’t see why the div would need to come into focus at all.

Any chance you can re-share the correct URL with the above change so I can take another quick look?

[Frank]

It’s live now. I changed the min.js back to the way it was. I also noticed the related products show the same behaviour, they all need a double tap before the links trigger.

[Tom]

I just gave it a try on my iPad and I’m not experiencing any issues. Any chance you can make a screen recording of the specific issue so I know exactly where to tap when I test?

Let me know 🙂

[Frank]

I think I figured it out, if you scroll with your finger touching one of the variations, it activates the variation focus. ( It creates a black border around the option when one of the variations is ‘focused’ ) If this is the case, both the related products items and the scroll to select options button needs to ‘defocus’ the variations first. Thank you very much for thinking and testing with me, I’ll see if I can find a way to solve this.

[Tom]

Ah, that makes sense – sometimes it’s necessary to “un-focus” something before clicking or tapping another target.

[Author]

Posts