1798131 - [X11] Tooltips stay and never disappear when Alt+Tabbing in Linux

Status: RESOLVED FIXED

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

Description

[Julien Wajsberg [:julienw]]

I'm using Gnome 3.38 on Debian Stable, and Firefox Nightly 20221025094808 (but I see this for some time now).

When I hover the mouse on something with a tooltip (such as a tab in the tab strip, or the hamburger menu), and then switch to another virtual desktop, the tooltip stays displayed and never disappear until I come back to the initial virtual desktop.

This doesn't seem to happen on thunderbird v91.13 20220908191136 so this might be a regression, I'll run a mozregression.

Comment 1

[Julien Wajsberg [:julienw]]

mozregression result: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=d1eb6fe5a1fa5457425c5a33f212516a5eeaa381&tochange=498e0e6f9b19107c8c17525a3d01a659f89002e8

This points to bug 1756903.

Comment 2

[Julien Wajsberg [:julienw]]

This happens also when I switch to another window in the same virtual desktop.

Comment 3

[Julien Wajsberg [:julienw]]

Attachment: Screencast_20221029_125247.webm

Comment 4

[Julien Wajsberg [:julienw]]

In this screencast, at the end I'm switching virtual desktop but for some reason the recorder doesn't see it :-) but you get the idea.

Comment 5

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

Set release status flags based on info from the regressing bug 1756903

:emilio, since you are the author of the regressor, bug 1756903, could you take a look? Also, could you set the severity field?

For more information, please visit auto_nag documentation.

Comment 6

[Emilio Cobos Álvarez (:emilio)]

Can you attach about:support contents? Presumably you're using X11, though it probably repros on Wayland as well.

Comment 7

[Julien Wajsberg [:julienw]]

Attachment: aboutsupport.json

sure, here it is!

Indeed it looks like I'm on X11 here. I kind of thought I was on XWayland... but maybe I switched some time ago and forgot to switch bacK.

Comment 8

[Emilio Cobos Álvarez (:emilio)]

Are you sure of the regression range? I can still reproduce with MOZ_GTK_TITLEBAR_DECORATION=system, which uses the old code-path...

Comment 9

[Emilio Cobos Álvarez (:emilio)]

Martin do you know how this is supposed to work? I don't see any particular code to hide tooltips on blur so my guess is that this is supposed to be handled by GTK...

Comment 10

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

It may be caused by different widget hierarchy. We hide tooltips on any event we get (keyboard/mouse) and that's handled by FF itself at nsXULTooltipListener::HideTooltip().

Comment 11

[Julien Wajsberg [:julienw]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #8)

Are you sure of the regression range? I can still reproduce with MOZ_GTK_TITLEBAR_DECORATION=system, which uses the old code-path...

Mmm definitely I don't reproduce with this env variable, on latest nightly 20221102094537, on my computer.

Comment 12

[Emilio Cobos Álvarez (:emilio)]

(In reply to Martin Stránský [:stransky] (ni? me) from comment #10)

It may be caused by different widget hierarchy. We hide tooltips on any event we get (keyboard/mouse) and that's handled by FF itself at nsXULTooltipListener::HideTooltip().

Hmm, but there's nothing that hides on window blur is it? Should CheckForRollup deal with tooltips somehow?

(In reply to Julien Wajsberg [:julienw] from comment #11)

(In reply to Emilio Cobos Álvarez (:emilio) from comment #8)

Are you sure of the regression range? I can still reproduce with MOZ_GTK_TITLEBAR_DECORATION=system, which uses the old code-path...

Mmm definitely I don't reproduce with this env variable, on latest nightly 20221102094537, on my computer.

Can you manage to capture a log with MOZ_LOG=Widget:5,WidgetPopup:5 MOZ_GTK_TITLEBAR_DECORATION=system? That might tell us where this stuff is handled in the working configuration... I still haven't managed to not reproduce this...

Comment 13

[Julien Wajsberg [:julienw]]

I took a profile with this profile + putting the logs in markers => https://share.firefox.dev/3zCw5Wj
Hopefully this will be even more useful :-)

BTW I see from the screenshots in this profile that we're missing the CompositorScreenshotWindowDestroyed for these "windows"... This seems to be the case also without MOZ_GTK_TITLEBAR_DECORATION=system. I'll file a bug about that.

Comment 14

[Julien Wajsberg [:julienw]]

I can try to do a rr recording if needed, tell me if that would be useful.

Comment 15

[Emilio Cobos Álvarez (:emilio)]

Can I see the native stack of a marker? In particular I want to know the stack of this one:

(WidgetPopup) [7f756d5c5000]: nsWindow::Show state 0 frame Frame(7f7576d6ba50) tooltip

Comment 16

[Julien Wajsberg [:julienw]]

I made another profile with the stacks for the log markers => https://share.firefox.dev/3T2GLV8

FTR, to get this, one has to add profilerstacks to MOZ_LOG.

Comment 17

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

Set release status flags based on info from the regressing bug 1756903

Comment 18

[Emilio Cobos Álvarez (:emilio)]

The stacks of the markers in comment 16 don't seem to work btw, they all have:

    XREMain::XRE_main
    (root)

Comment 20

[Julien Wajsberg [:julienw]]

From bug 1803058, it looks like it's not just Gnome but also KDE.

Comment 21

[Julien Wajsberg [:julienw]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #18)

The stacks of the markers in comment 16 don't seem to work btw, they all have:

    XREMain::XRE_main
    (root)

It is super weird, some logs do have proper stacks but most don't... I'll do another profile for you.

Comment 22

[Julien Wajsberg [:julienw]]

Sadly I'm hitting bug 1779257... No native stacks for markers on Linux until somebody fixes this unfortunate bug.

Comment 23

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1798131 - Fix leave-notify handling on X11 (and stop doing pointer grabbing there). r=stransky

The main issue is the confusion between mGdkWindow and the toplevel when
we draw with client decorations. Though something else broke since we
enabled them and now even with MOZ_GTK_TITLEBAR_DECORATION=system the
bug reproduces.

The thing that's supposed to hide the tooltip on nsXULTooltipListener is
the mouseout event handler, but without this fix we would upgrade the
eMouseExitFromWidget to a synthesized mouse move here:

https://searchfox.org/mozilla-central/rev/2fc2ccf960c2f7c419262ac7215715c5235948db/dom/events/EventStateManager.cpp#721-732

Make leave-notify handling properly parallel to enter-notify in order to
properly notify gecko of the mouse leaving the window, thus fixing the
bug.

Comment 24

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7c3b662ef3fc
Fix leave-notify handling on X11. r=stransky

Comment 25

[Cosmin Sabou [:CosminS]]

Backed out for turning Bug 1775659 into permafail on linux.

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&resultStatus=testfailed%2Cbusted%2Cexception%2Csuccess%2Cusercancel%2Crunning%2Cpending%2Crunnable&searchStr=linux%2C18.04%2Cx64%2Cwebrender%2Copt%2Cmochitests%2Cwith%2Csoftware%2Cwebrender%2Cenabled%2Ctest-linux1804-64-qr%2Fopt-mochitest-browser-chrome-swr%2Cbc1&fromchange=2bb0a039dfbf818ffad9da316e78a7cc6833b010&tochange=b193708ccc3e02cca0464ce2f783c6fec5fbe98a&selectedTaskRun=Anw7CHlfQ0SSFwKCkwAmHw.0

Failure log: https://treeherder.mozilla.org/logviewer?job_id=398506761&repo=autoland

Backout link: https://hg.mozilla.org/integration/autoland/rev/0cda34ba739113cc7e411f6b1676f43d9c0ef93e

Comment 26

[Emilio Cobos Álvarez (:emilio)]

Wow, what a mess, see the updated commit message o.O

Comment 28

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9b1c242dc2e0
Fix leave-notify handling on X11 (and stop doing pointer grabbing there). r=stransky

Comment 29

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/9b1c242dc2e0

Comment 31

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

Copying crash signatures from duplicate bugs.

Comment 32

[Intermittent Failures Robot]

213 failures in 3510 pushes (0.061 failures/push) were associated with this bug in the last 7 days.

This is the #1 most frequent failure this week.

** This test has failed more than 150 times in the last 21 days. It should be disabled until it can be fixed. **

Repository breakdown:

• autoland: 149
• mozilla-central: 33
• try: 15
• mozilla-esr102: 2
• mozilla-beta: 2
• mozilla-release: 11
• comm-central: 1

Platform and build breakdown:

• linux1804-64-qr: 128
  • debug: 33
  • opt: 95
• linux1804-64-asan-qr: 16
  • opt: 16
• linux1804-64-shippable-qr: 60
  • opt: 60
• linux1804-64-devedition-qr: 6
  • opt: 6
• linux1804-64-tsan-qr: 3
  • opt: 3

For more details, see:
https://treeherder.mozilla.org/intermittent-failures/bugdetails?bug=1798131&startday=2022-12-05&endday=2022-12-11&tree=all

Comment 33

[Julien Wajsberg [:julienw]]

Hey Emilio, I'm running with Nightly 20221213041109, but it looks like it still happens here.
This Firefox runs on xwayland.
On my other Firefox running on wayland, this doesn't happen as expected.
Is there anything you'd like me to try?

Comment 34

[Emilio Cobos Álvarez (:emilio)]

I can't repro on the latest nightly on either X11 nor XWayland (nor Wayland of course). I'm using a keyboard shortcut to switch virtual desktops. Before the patch, I could trivially reproduce on X11 by just Alt+Tab-ing to move the Firefox window behind another.

I added some logging here that should show up when switching desktops (if it doesn't then it's an X server bug I suspect). Do you see that? Let's file another bug if you can still repro, with more details about your set-up? I'm using a keyboard shortcut to switch virtual desktops and I don't see this, but the virtual desktop switch on my machine has a rather fancy animation, so maybe we're not using the same setup.

Comment 35

[Julien Wajsberg [:julienw]]

This doesn't reproduce with MOZ_GTK_TITLEBAR_DECORATION=system but this does reproduce without it. I'll file a separate bug.

Comment 36

[Intermittent Failures Robot]

3 failures in 3558 pushes (0.001 failures/push) were associated with this bug in the last 7 days.

Repository breakdown:

• try: 1
• mozilla-esr102: 1
• mozilla-central: 1

Platform and build breakdown:

• linux1804-64-qr: 2
  • debug: 2
• linux1804-64-ccov-qr: 1
  • opt: 1

For more details, see:
https://treeherder.mozilla.org/intermittent-failures/bugdetails?bug=1798131&startday=2022-12-12&endday=2022-12-18&tree=all

Comment 37

[Intermittent Failures Robot]

1 failures in 2999 pushes (0.0 failures/push) were associated with this bug in the last 7 days.

Repository breakdown:

• autoland: 1

Platform and build breakdown:

• linux1804-64-tsan-qr: 1
  • opt: 1

For more details, see:
https://treeherder.mozilla.org/intermittent-failures/bugdetails?bug=1798131&startday=2022-12-19&endday=2022-12-25&tree=all

Comment 38

[Ryan VanderMeulen [:RyanVM]]

This was backed out from 109 for the RC2 build to avoid shipping bug 1805939.
https://hg.mozilla.org/releases/mozilla-release/rev/d6f4c3448906