Late firing on mobiles

Question

Late firing on mobiles

arvgta opened this issue 8 years ago · comments

I used to use this great plugin internally for this project.

Unfortunately, it was firing inadequately on mobiles (very late).
So I reverted to jQuery's hover which fires much quicker but without the faulty behaviour of hoverIntent.

Is it possible to patch this issue? I would love to revert back to hoverIntent then...

Usman · Answer 1 · Tue Oct 11 2016 00:57:11 GMT+0800 (China Standard Time)

Hi @arvgta, and thanks for opening this issue.

Can you please provide a link to a JSFiddle (or similar) that simply & reliably demonstrates the issue you experienced? Please also specify which mobiles & browsers experience the issue.

(Also, which version of the plugin are you using? The last tagged v1.8.1, or the latest version from master? This may have been fixed and could just be waiting to be tagged+released...)

Thanks for the input, and I await your demo of the issue. :)

Arvind Gupta · Answer 2 · Tue Oct 11 2016 14:22:43 GMT+0800 (China Standard Time)

Hi @usmonster,

thanks for the rapid reply. The version I was using was indeed old (2003 / 2004).
Glad to here that it may have been fixed - great!

Could you please point me to the latest version, and I will retry it in my project.

(It's cumbersome to make a fiddle with my plugin - I would just go ahead and re-integrate the latest version of hoverIntent in Ajaxify

EDIT: Just tried out the latest hoverIntent code for a new Ajaxify version - problem persists...
What is basically happening is that, e.g. in the responsive view of Chrome hoverIntent is firing after the click event, which is in turn causing Ajaxify to crash hard.

I do not have this issue with jQuery's built-in hover.

The bug has been reported to me to be on e.g. iPads, other iOS devices and some Android versions.

I would love to use hoverIntent again, because it saves a lot of bandwidth in a very intelligent way!

A quick question - is this hoverIntent call alright? ->

if (prefetch) $(selector).hoverIntent(_prefetch, function(){});

(if the second argument is not acceptable - that would explain, why the _prefetch handler is being called twice)

I'll leave the faulty version online on 4nf.org over night - as the demo you requested!

You can clearly see that everything's fine on the desktop but not so on a mobile...

Thanks for your support!

Usman · Answer 3 · Wed Oct 12 2016 02:10:18 GMT+0800 (China Standard Time)

Hi @arvgta. Thanks for the follow-up!

It appears that the way you're calling the plugin is fine, though I really can't help fix the issue without a link to a simple demo of the bug and steps to reproduce the bad behavior.

Yes, it may be cumbersome, but bug reporters often realize that the bug is in their own code when they start to make a simple demo. Even if it's a real bug in the plugin, it's much easier to debug, identify, and fix when it's not surrounded by an entire website's worth of markup, CSS, and unrelated JS. ;) I hope you understand!

Arvind Gupta · Answer 4 · Wed Oct 12 2016 14:38:04 GMT+0800 (China Standard Time)

Hi @usmonster. Thanks for your quick response, once again!

To cut a long story short - here's the fiddle I made, with bargain-basement logic.
(Sorry, I didn't realise, how easy it is to make a fiddle - it was my first...)

Please open the console in Chrome and then toggle the device mode in the Chrome console to "responsive" prior to running the Fiddle.

What I see is, as suspected:

Normal click!
HoverIntent fired!

i.e. the normal click firing before hoverIntent

When in desktop view, everything is alright with this output:

HoverIntent fired!
Normal click!

I had a look at the hoverIntent code and must admit that there doesn't seem that much room for such an error - so I'd love to help you out, but don't know what the reason might be right now, unfortunately...

In a first step, let's agree on that the behaviour described above is not, what it should be - i.e. the output should be like on the desktop for both test scenarios?

Then I'd suggest having a look at the code together?

Thanks again!

Arvind Gupta · Answer 5 · Tue Oct 18 2016 13:43:42 GMT+0800 (China Standard Time)

Hi @usmonster, could you please indicate, whether we want to fix this issue any time soon?

Usman · Answer 6 · Tue Oct 18 2016 15:24:16 GMT+0800 (China Standard Time)

Hi @arvgta! I didn't get to investigate in depth, but this might simply be caused by the natural event order of touch-based actions:

Basically, hoverIntent introduces a default delay after mouseenter before the callback is fired. For touch actions, there is no mouseenter event until the very moment of the touch, so it's completely normal and expected that the click happens first in this configuration. Basically, it's working as expected.

Depending upon your use case, a workaround for you might be to conditionally set the interval option to 0 when you initialize hoverIntent if you detect touch events.

It's still uncertain if touch events will ever be handled in the plugin itself, but I'll take a look at what happens with plain .hover and decide later. I'll open a new issue if we decide to fix it, but for now I'll close this one, if that's OK.

Hope this answers all your questions!

Arvind Gupta · Answer 7 · Tue Oct 18 2016 16:02:24 GMT+0800 (China Standard Time)

Hi @usmonster, thanks for elaborating on the issue. Thanks for the links, too!

From a hoverIntent user's point of view, I would still maintain, that the behaviour is not, what one would expect by default. When you test against jQuery's normal hover, you ought to find, that the behaviour is different. I understand, that it is part of the strategy of hoverIntent to have a user interface similar to hover? Ideally, the behaviour of both at run-time should be similar, too, only with hoverIntent being a bit smarter?

Thanks for the suggested workaround for my use case. I have to decide now, how to handle this irregularity, if I decide to enjoy hoverIntent in the future.