Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

delay should be applied to hoverIntent not superfish #120

Open
mjau-mjau opened this issue Aug 2, 2014 · 3 comments
Open

delay should be applied to hoverIntent not superfish #120

mjau-mjau opened this issue Aug 2, 2014 · 3 comments
Labels

Comments

@mjau-mjau
Copy link

Just thought I'd remark that delay should be applied to the hoverIntent plugin (if enabled) instead of to superfish. Why? Because on "mouse-piloting errors", once the mouse is again over the menu element (within delay), it re-triggers hoverIntent which will not trigger "open" again until intent is determined ... this will often cause an animated menu to flash close/open while the mouse is back over the item.

To avoid this, one should be using the hoverIntent timeout setting instead, which prevents over/out handlers from firing when they shouldn't. timeout as quoted from hoverIntent docs:

A simple delay, in milliseconds, before the "out" function is called. If the user mouses back over the element before the timeout has expired the "out" function will not be called (nor will the "over" function be called). This is primarily to protect against sloppy/human mousing trajectories that temporarily (and unintentionally) take the user off of the target element... giving them time to return. Default timeout: 0

Personally, I added the hoverIntent timeout manually, and just kept superfish delay to 0:

// $menu.hoverIntent(over, out, targets);
// fixed timeout delay to work in hoverintent instead of superfish:
$menu.hoverIntent({
  over: over,
  out: out,
  selector: targets,
  timeout: 300
});
@joeldbirch
Copy link
Owner

Thanks for noticing this and explaining exactly what is going on. I wanted Superfish to have a built-in delay for those who don't use hoverIntent for whatever reason, but given that nowadays it is required for various touch devices to be supported maybe I should just make hoverIntent a firm requirement. Thanks for providing a workaround in the meantime.

@joeldbirch joeldbirch added the bug label Mar 4, 2015
@girish-khadse
Copy link

Facing this issue. Could you please give more details about this solution? Where should we add above mentioned code?

@joeldbirch
Copy link
Owner

I have created a branch named 'hoverintent' which has this patch in but I am not seeing any noticeable difference in behaviour. In which browsers are you seeing the "flash close/open" behaviour, and does this new branch behave any differently in it? Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants