Last modified: 2014-06-06 06:01:01 UTC
Created attachment 15424 [details] screenshot After a recent update, hovercards pop up above the mouse cursor if the hovered link is located on the bottom half of the page. The problem is, that the hovercard (or the small tip to be exact, see screenshot) is generated directly under the mouse cursor. This results in fast flickering of the hovercards since as soon as the hovercard pops up, the link is shadowed, therefore triggering the hovercard to be hidden. As soon as the hovercard is hidden, the link is not shadowed anymore, triggering the hivercard to be shown again The above happens for me on Windows 7 using Firefox 29.0.1 (I tried the same with Internet Explorer 11 but there the hovercards where pretty much broken anyway)
Confirmed, also on Firefox 29, throughout mediawikiwiki. It seems to only be a problem when the Hovercard appears *above* the link/mouse-cursor.
*** Bug 65652 has been marked as a duplicate of this bug. ***
Screencast: https://bugzilla.wikimedia.org/attachment.cgi?id=15457
please see bug 62971, comment 12. i believe the problem here comes from incorrect placement of the hovercard, so displaying it causes a "mouseout" event. (the very annoying flicker also demonstrate the well known and unrelated fact that the delay before showing the hovercard is too short - many users complain that innocently moving the mouse across the article causes hovercards to jump. there is no good reason to have shorter than 500 or even 700 ms delay). i believe that placing the hovercard by setting css "bottom" instead of "top" would have prevented this issue (explain the hypothesis: we ask the hovercard how tall it is before it's actually displays, which gives slightly incorrect answer. since we calculate "top" based on the height of the card, it ends up too low, so when it displays, it inserts itself between the mouse pointer and the element. this triggers a "mouseout" event for the element, but not "mouseenter" event for the hovercard itself). we can crudely make this bug almost disappear by setting the "top" 20 or so pixels higher, or we can really fix it by setting css "bottom" instead of "top" when "flippedY" is true. peace.
This also makes the links unclickable.
The issue was being caused on Firefox because it wasn't handling the mouseenter/mouseleave events of the animating elements in an unpredictable manner. This wasn't happening for non flipped cards. Flipping the animation for flipped hovercards (which should be part of the design now) fixed the problem. The following patches should resolve it - 1. https://gerrit.wikimedia.org/r/#/c/135549/ 2. https://gerrit.wikimedia.org/r/#/c/135552/ 3. https://gerrit.wikimedia.org/r/#/c/135554/
Created attachment 15507 [details] chrome screencast The problem is slightly different in Chrome. It's /usually/ stable, but if I move the mousepointer over the link, it sometimes interferes with the Hovercard-arrow, causing the popup to vanish-and-reappear. This can most clearly be demonstrated by sliding to the right, over a link. See screencast attached.
(In reply to Quiddity from comment #7) I tested this with the patch and it should get resolved too.
*** Bug 65899 has been marked as a duplicate of this bug. ***
Created attachment 15555 [details] screencast 2 (smaller issue) (In reply to Prateek Saxena from comment #8) I've just tested the patched code, at http://en.wikipedia.beta.wmflabs.org/wiki/Main_Page (Thanks Yuvi!) The Critical problem, of "I can't click the damn links in the bottom half of my screen!" is solved. (There is no longer an infinite cycle of flicker). I would support these code-changes getting SWAT deployed (if possible) for this reason alone. However, there is still an occasional single-flicker. It's not consistent, and doesn't interfere with clicking - it's just a smaller aesthetic problem. See screencast - (Note: I've gotten practiced at triggering the issue, hence 2 examples in quick succession. It's usually less frequent.). Possibly the (discussed elsewhere) changes to the default timing (from 150ms to 500ms), will help resolve that aspect.
also tested, works for me. Dan?
(In reply to Quiddity from comment #10) > It's not consistent, and doesn't interfere with clicking - it's just > a smaller aesthetic problem. I am not able to replicate this. I tried both on Firefox and Chrome trying to replicate the movements from your screencast. Any tips? > Possibly the (discussed elsewhere) changes to the default timing (from > 150ms to 500ms), will help resolve that aspect. We could test this over localtunnel next time you we are online on IRC?
I am able to replicate it on Ubuntu/Chrome sometimes, but still not very often (as Quiddity had mentioned). I'll try and patch this issue as and when I keep getting access to a Linux machine. Can we close this bug and open a more specific one for this?
The initially reported bug seems to be fixed now. Thank you! Take note of the related follow-up bug 66221 though. @Quiddity: Will you open a separate bug report for your specific problem (which I'm not able to reproduce on Windows 7 / Firefox 29.0.1 either)?
(In reply to Eduard Braun from comment #14) > @Quiddity: Will you open a separate bug report for your specific problem > (which I'm not able to reproduce on Windows 7 / Firefox 29.0.1 either)? Opened as bug 66240
