In certain repeatable cases, the "qtip-hover" class does not properly get removed from menu items even after moving away from a menu item. Then, when you go to hover over a second menu item, the previous one appears to get "stuck" in the hover state, and you end up with two menu items with their hover state active. yuck.
This is especially noticeable if you have a background color change attached to the target menu item synced with the "qtip-hover" class.
I suspect the root of the issue is that if you hover your mouse across a series of menu items sufficiently rapidly, the beforeHide callback that is used to remove the hover class never actually gets called. This could be because the show effect had a slight delay, or that the qtip didn't have a chance to finish its "show" routine and qtip wasnt in a state where it was actually able to be hidden.
Patch provided in first comment below ensures that all qtip-hover classes are removed from the page, before adding the hover-state to the currently hovered item.
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | menu_minipanels-n1425046-8.patch | 1.04 KB | damienmckenna |
| #6 | menu_minipanels-clear-existing-hover-states-1425046-4.patch | 1.04 KB | jwilson3 |
| #2 | menu_minipanels-n1425046-2-d6.patch | 669 bytes | damienmckenna |
| #2 | menu_minipanels-n1425046-2-d7.patch | 662 bytes | damienmckenna |
| #1 | menu_minipanels-clear-existing-hover-states-1425046.patch | 521 bytes | jwilson3 |
Comments
Comment #1
jwilson3Comment #2
damienmckennaI've simplified this further.
Comment #3
damienmckennaI've committed this.
Comment #4
jwilson3The
beforeHidecould be the wrong place to put this because, as mentioned in the issue summary, that is exactly the code that *doesn't* get called on time, which is why I put the code inbeforeShow, to ensure that before showing another mini-panel, all others are cleared.Hopefully, I'll get some time on the project where this was affected this week to try your version of the fix out.
Comment #6
jwilson3Clients are complaining that the hover state is sticking again, after updating to the latest version that uses the patches in #3.
My hunch on #4 was correct, and here is another patch that ensures that the hover state gets removed *just* before it gets added to the target that triggered the event, by removing it as part of the same
beforeShowevent.This is not to say that the code addition in
beforeHideis wrong, because it is also needed to hide the element in normal cases. I just found that this event is not always triggered for some reason.Comment #7
jwilson3Comment #8
damienmckenna@jwilson3: Thanks for the patch. Does this alternative one work on all of your sites?
Comment #9
jwilson3Damien:
Actually, i initially thought that a patch like #8, would work too, and was what I tried first, but it didn't work because the hover class never gets removed (except when going to hover another menu item). I mentioned this in #6 and will repeat here that the code triggered by
beforeHideis still needed, in order to remove the hover class for all normal cases, after someone's mouse exists the active qtip.The patch in #6, I think is the definitive solution to the problem:
a) remove hover state on beforeHide.
b) add hover state on beforeShow.
c) also, clear any left over hover states on beforeShow.
Please rework #8, to look more like #6 if you want to change the comments which i was liberal about updating, or use #6 if it works for you.
Comment #10
damienmckennaCommitted to both branches. Thanks James!