1680920 - Title-text tooltip for an image appears and then instantly disappears again

Status: RESOLVED DUPLICATE of bug 1676020

(Core :: Widget: Gtk, defect, P3)

Description

[Simon Tatham]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:83.0) Gecko/20100101 Firefox/83.0

Steps to reproduce:

Started Firefox. Navigate to any web page that contains an image with a "title" attribute, such as https://xkcd.com/. Mouse over the image, in order to read its title-text.

Actual results:

A tooltip window containing the title text pops up under the mouse, but after a fraction of a second, it disappears again. I had not moved the mouse at all after the initial motion that caused the tooltip to appear.

Expected results:

The tooltip window should remain in place until at least the next time I move the mouse.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Simon Tatham]

I've observed this problem with Firefox on Linux, under XFCE (so, X11 rather than Wayland).

I've tested it on three different computers, all running Firefox 83, on two different versions of Ubuntu. On two of the machines, the problem occurs; on the third, it doesn't. But I'm not sure what the distinguishing factor is. It's certainly not Ubuntu version: the working machine is 20.04, and the failing machines are 20.04 and 18.04.

My best guess is that it might have something to do with display resolution, for reasons that I'll explain in the next comment...

Comment 3

[Simon Tatham]

I tried installing the Ubuntu firefox-dbg package and running Firefox under -g. I don't know the code base at all, but I put a breakpoint on XUnmapWindow (to trigger when the tooltip vanishes), and following a long trail of breadcrumbs from there, it appeared to be in response to a mouse-out / LeaveNotify event.

So I traced the X11 event stream, on the working machine and one of the failing ones, using my own tool xtruss, and indeed, I saw a LeaveNotify on the failing machine and not on the working one. The key parts, I think, were these:

On the machine where this works OK, the final MotionNotify that positions the mouse over the image, and the responding ConfigureWindow that sets up the tooltip position and size, looked like this:
03200000: --- MotionNotify(root=w#000005FD, event=w#03200010, child=None, same-screen=True, root-x=1511, root-y=941, event-x=269, event-y=913, detail=Normal, state=0x0000, time=0x00015CBF)
03200000: ConfigureWindow(window=w#03200039, x=1506, y=951, width=533, height=96)
So the mouse moves over the image at (1511,941), and we configure the tooltip window to have its top-left corner at (1506,951): five pixels left and ten pixels below the mouse location.

But on the machine where it fails, those events look like this:
04c00000: --- MotionNotify(root=w#000006C7, event=w#04C00003, child=None, same-screen=True, root-x=1968, root-y=1075, event-x=437, event-y=651, detail=Normal, state=0x0000, time=0x0E23C22F)
04c00000: ConfigureWindow(window=w#04C0002D, x=1963, y=1074, width=533, height=96)
So the mouse moved over the image at (1968,1075), and we responded by configuring the tooltip's top left corner to be at (1963,1074): five pixels left and one pixel above the mouse location. So the popup appears underneath the mouse pointer on the failing machine, where it didn't on the working one.

And then, not very surprisingly, the X server promptly sends LeaveNotify events for the windows that previously contained the mouse, and an EnterNotify for the one that now does (the tooltip itself). As closely as I can tell from my inexpert debugging inside Firefox, those LeaveNotify events appear to be what's causing the confusion, and certainly they are a difference between the two machines.

So I think that the underlying issue is that the popup is positioned differently relative to the mouse pointer, in such a way that on one machine the mouse pointer location itself is outside the popup window bounds, and on the other, it's inside them.

That's why I speculate that DPI might have something to do with it: on the two failing machines I use a large but conventional-resolution monitor, but the one where it works is a laptop with a high-DPI display.

I've spent an afternoon running Firefox under gdb and capturing traces with xtruss, and I'm entirely prepared to do some more of that if I can have a clue or two what to look for!

Comment 4

[Simon Tatham]

Attachment: worked.xtruss

Comment 5

[Simon Tatham]

Attachment: failed.xtruss

Attached the full xtruss output from the working and failing cases, in case somebody more expert can see further clues.

(These were two-second captures of the X11 display traffic, not a full run of Firefox, which would be a great deal larger!)

Comment 6

[Simon Tatham]

Per the bug-writing guidelines, I tried this in a clean Firefox profile. On the machine where it fails, it still fails in a new profile.

Bug #849591 looks like a very similar symptom, except that it's 8 years ago and on Windows!

Comment 7

[Martin Stránský [:stransky] (ni? me)]

Can you try a different desktop like Gnome? Also is that a recent regression?
Thanks.

Comment 8

[Simon Tatham]

It's a recent regression in the sense of "some time this year", although I'm sorry to say that I can't remember exactly which Firefox update made it start happening. I've delayed reporting it because I've been trying to find the time to collect enough information for it to be useful.

Good call on the different desktop. I've just logged out of my usual XFCE and into Gnome (still on X11), and there, the tooltip appears well below the mouse pointer (its top edge is below even the bottom end of the arrow), and doesn't immediately disappear.

So it's not the display resolution making the difference, because that's the same between the two environments. Perhaps it's something to do with different font configuration -- is one of the distances involved measured in ems, perhaps?

Comment 9

[Martin Stránský [:stransky] (ni? me)]

Please try to use a mozregression tool to find exact regression range, how-to is here:
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems?rd=Bug_info_Firefox#Use_Mozregression_tool
Thanks.

Comment 10

[Simon Tatham]

That's a pretty cool tool!

6:31.97 INFO: Last good revision: f56158e0fd578f54c4a7307eda87c1c350032136
6:31.97 INFO: First bad revision: 9b17a5aeded6590078ba7bad625d126a9cf3edd0
6:31.97 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=f56158e0fd578f54c4a7307eda87c1c350032136&tochange=9b17a5aeded6590078ba7bad625d126a9cf3edd0

Comment 11

[Simon Tatham]

Ah, which makes this probably a dupe of bug #1676020 (listed under "regressions" in bug #1566422 which that commit cites).

I searched for "vanish" and "disappear" when trying to find existing instances of this bug, but didn't think of "flash off"!

Comment 12

[Simon Tatham]

And that issue is cataloguing the problem by window manager, which means I should probably mention that I'm running Sawfish rather than the XFCE default WM.

Comment 13

[Martin Stránský [:stransky] (ni? me)]

Cool, Thanks.