Wikimedia Bugzilla is closed!

the solution is simple: display the card based on mouse location rather than the location of the element that triggered it.

there are other reasons for this: e.g., one might want to create a card for large elements (say, hovercard for an image), and the expectation is that the card will be near the mouse pointer, not fixed based on element location, which may be pretty far from the mouse for large element.

btw - this is the way browsers display tooltips: if you have an image tooltip, it will show relative to the mouse, not to the image, so doing it the way i describe is meeting users' expectations.

peace.

Agree, Discussed with Prateek.

(In reply to Vibha Bamba from comment #2)
> Agree, Discussed with Prateek.

i posted on [[mw:Extension talk:Popups]] [1] an outline of how i think this could/should be implemented.

peace.

______________________________
hope this link works - otherwise treat it as text: "Extension talk:Popups: on mw wiki. no "preview" on bugzilla...

Change 125577 had a related patch set uploaded by Prtksxna:
Position hovercard according to mouse position

https://gerrit.wikimedia.org/r/125577

The issue with this approach is that sometimes the hovercard will collide with the link. This will happen if the mouse entered the link from the top.

The event gets triggered as soon as the mouse enters the link and that position is taken for placement, the mouse might have moved in this much time. If we move the hovercard along with mouse movement it'll become like the sample that Dan has shown during the meeting - is that something we want? - I don't.

Created attachment 15091 [details]
fixedissue

(In reply to Prateek Saxena from comment #5)
> The issue with this approach is that sometimes the hovercard will collide
> with the link. This will happen if the mouse entered the link from the top.
> 
> The event gets triggered as soon as the mouse enters the link and that
> position is taken for placement, the mouse might have moved in this much
> time. If we move the hovercard along with mouse movement it'll become like
> the sample that Dan has shown during the meeting - is that something we
> want? - I don't.

since the whole card serves as a link, obscuring the link does not seem like such a problem to me. i think this is the correct behavior, since we have no control over the element: it can be a very ling title, that spans the whole line, and of course, when the link gets word-wrapped, there is no way to place the card based on the element location that will work as expected in all cases (remember that browser's tooltip are poped relative to the mouse pointer).

if this seems critical, it should be easy enough to take the element location into consideration and make a slight adjustment to try and not obscure the element, but the location should be based the mouse pointer and not the element.

peace.

Prateek, any pending concerns here?

(In reply to Vibha Bamba from comment #8)
> Prateek, any pending concerns here?

i have a small concern: the event that triggers the popup can be either "mouseenter" or "focus".
 
now, "focus" events do not contain viable "pageX" and "pageY" fields, so it may be better to do something like:

offsetTop = (event.type == 'mouseenter'
    ? event.pageY + 20 
    : $el.offset().top + $el.height() + 9);

and similarly for offsetLeft.

no? 

peace.

(In reply to Prateek Saxena from comment #5)
[..]
> time. If we move the hovercard along with mouse movement it'll become like
> the sample that Dan has shown during the meeting - is that something we
> want? - I don't.

We definitely don't want it to move-around once visible. (Eg. Hovering on the items in the table lower down on this page: http://www.wowhead.com/items ) Because that's annoying, and it makes it impossible to click the popup!

But the way that Navpopups does it, would be fine, and solve this bug. (It opens the popup wherever the mouse comes-to-rest, and ignores subsequent movements as long as the mouse is still over the link or the popup.)

(In reply to kipod from comment #9)
> i have a small concern: the event that triggers the popup can be
> either "mouseenter" or "focus"

Thanks for pointing this out, I'll update the patch.

Change 125577 merged by jenkins-bot:
Position hovercard according to mouse position

https://gerrit.wikimedia.org/r/125577

This looks fixed, too.