Hovercards popping up above cause flickering (because of popping up under the mouse cursor)
Closed, ResolvedPublic

Description

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)


Version: unspecified
Severity: major

Attached:

bzimport added a project: Hovercards.Via ConduitNov 22 2014, 3:19 AM
bzimport set Reference to bz65433.
Patrick87 created this task.Via LegacyMay 17 2014, 12:06 PM
Quiddity added a comment.Via ConduitMay 17 2014, 11:20 PM

Confirmed, also on Firefox 29, throughout mediawikiwiki.

It seems to only be a problem when the Hovercard appears *above* the link/mouse-cursor.

Quiddity added a comment.Via ConduitMay 22 2014, 7:31 PM
  • Bug 65652 has been marked as a duplicate of this bug. ***
Kipod added a comment.Via ConduitMay 22 2014, 9:56 PM

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.

He7d3r added a comment.Via ConduitMay 23 2014, 3:39 PM

This also makes the links unclickable.

Prtksxna added a comment.Via ConduitMay 27 2014, 12:51 PM

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/
Quiddity added a comment.Via ConduitMay 28 2014, 8:53 PM

Created attachment 15507
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.

Attached:

Prtksxna added a comment.Via ConduitMay 29 2014, 4:21 AM

(In reply to Quiddity from comment #7)

I tested this with the patch and it should get resolved too.

Quiddity added a comment.Via ConduitMay 29 2014, 5:51 PM
  • Bug 65899 has been marked as a duplicate of this bug. ***
Quiddity added a comment.Via ConduitJun 2 2014, 8:37 PM

Created attachment 15555
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.

Attached:

Vibhabamba added a comment.Via ConduitJun 2 2014, 8:46 PM

also tested, works for me. Dan?

Prtksxna added a comment.Via ConduitJun 3 2014, 4:15 AM

(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?

Prtksxna added a comment.Via ConduitJun 4 2014, 5:47 AM

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?

Patrick87 added a comment.Via ConduitJun 5 2014, 10:05 PM

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)?

Quiddity added a comment.Via ConduitJun 6 2014, 6:01 AM

(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

Prtksxna raised the priority of this task from "High" to "Needs Triage".Via WebDec 3 2014, 5:29 AM
Prtksxna moved this task to Archive on the Hovercards workboard.

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.