2050687 - [kde/wayland] Browser toolbox doesn't show

Status: RESOLVED FIXED

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

Description

[Emilio Cobos Álvarez [:emilio]]

I run nightly with the browser toolbox enabled, but as of the last week or two (since I updated to plasma 6.7 I believe?) it no longer shows when I hit the shortcut (Ctrl+Alt+Shift+I).

It doesn't happen if I disable wayland (MOZ_ENABLE_WAYLAND=0) and doesn't happen either on GNOME.

It very annoyingly doesn't happen on a clean profile (but I have this happen on two machines), so I can't easily bisect Firefox.

I also can't log the browser toolbox because well, it nulls out MOZ_LOG.

Once I click the shortcut, I see in ps -ax something like:

98290 ?        Sl     0:14 /home/emilio/firefox/firefox-bin -foreground -profile /home/emilio/.config/mozilla/firefox/stlcj4jg.default-nightly/chrome_debugger_profile -chrome chrome://devtools/content/framework/browser-toolbox/window.html

But no visible window whatsoever. If I launch /home/emilio/firefox/firefox-bin -foreground -profile /home/emilio/.config/mozilla/firefox/stlcj4jg.default-nightly/chrome_debugger_profile, then the window pops up (along with an existing firefox window), which is really suspicious.

Vlad, long shot, but you don't happen to know if there have been changes along this area on Kwin right? (Or any easy way of debugging the kwin side of this).

FWIW, from code inspection we're not doing the XDG_ACTIVATION_TOKEN dance, and we probably should... Anyways will try to get to the bottom of this because it's pretty annoying.

Comment 1

[Vlad Zahorodnii [:zzag]]

In FF stable, the toolbox works for me. At least I see a connection prompt.

Vlad, long shot, but you don't happen to know if there have been changes along this area on Kwin right? (Or any easy way of debugging the kwin side of this).

The best what comes to my mind is run FF with WAYLAND_DEBUG=1 and then look after xdg_toplevel.close events. kwin itself shouldn't close dialogs left and right, only due to explicit user input.

From what I can tell, Nightly doesn't really do anything in response to key events. It sends no relevant requests to kwin. I see no get_toplevel or get_popup.

Comment 2

[Emilio Cobos Álvarez [:emilio]]

You need to enable it in the DevTools settings first fwiw, so if you don't regularly use nightly that might be why.

Comment 3

[Emilio Cobos Álvarez [:emilio]]

To be clear it's not about dialogs getting closed or anything, it's just the window isn't shown at all...

Comment 4

[Vlad Zahorodnii [:zzag]]

(In reply to Emilio Cobos Álvarez [:emilio] from comment #2)

You need to enable it in the DevTools settings first fwiw, so if you don't regularly use nightly that might be why.

Yeah I did that in developer tools' settings.

Comment 5

[Emilio Cobos Álvarez [:emilio]]

Attachment: WAYLAND_DEBUG of the browser toolbox process.

Not sure that gives you any info? It seems we're trying to render stuff...

Comment 6

[Emilio Cobos Álvarez [:emilio]]

I'll look at the Firefox side logging etc to see if I spot something. I think we also should pass the activation token to the toolbox to be good citizens in general...

Comment 7

[Vlad Zahorodnii [:zzag]]

(In reply to Emilio Cobos Álvarez [:emilio] from comment #5)

Created attachment 9602770 [details]
WAYLAND_DEBUG of the browser toolbox process.

Not sure that gives you any info? It seems we're trying to render stuff...

Some wl_surfaces are created but no xdg_toplevel or xdg_popup is created. This is the problem.

Comment 8

[Vlad Zahorodnii [:zzag]]

Creating a dialog should look something like

[3579440.960] {Default Queue}  -> wl_compositor#4.create_surface(new id wl_surface#42)
[3579493.909] {Default Queue}  -> xdg_wm_base#3.get_xdg_surface(new id xdg_surface#45, wl_surface#42)
[3579493.915] {Default Queue}  -> xdg_surface#45.get_toplevel(new id xdg_toplevel#46)

Comment 9

[Emilio Cobos Álvarez [:emilio]]

We don't do anything magic afaict, and in fact the toplevel is created if I launch firefox to the foreground again...

Comment 10

[Emilio Cobos Álvarez [:emilio]]

Ah, the widget logs show the issue. Martin, we're bailing out here

86625> [Parent 86625: Main Thread]: D/Widget [7f802d9f6000]: nsWindow::Create()
86625> [Parent 86625: Main Thread]: D/Widget [7f802d9f6000]:   mBounds: x:0 y:0 w:2 h:2
86625> [Parent 86625: Main Thread]: D/Widget [7f802d9f6000]:   parent window [0]
86625> [Parent 86625: Main Thread]: D/Widget [7f802d9f6000]:   nsWindow::Create() Initial resize to 1 x 1
86625> [Parent 86625: Main Thread]: D/Widget [7f802d9f6000]:   nsWindow::Create() Toplevel
86625> [Parent 86625: Main Thread]: D/Widget moz_container_init
86625> [Parent 86625: Main Thread]: D/Widget moz_container_realize() [7f802d9f6000] GdkWindow 7f802d4a6280
86625> [Parent 86625: Main Thread]: D/Widget [7f802d9f6000]: nsWindow::SetGdkWindow() 7f802d4a6280
86625> [Parent 86625: Main Thread]: D/Widget [7f802d9f6000]: Get NS_NATIVE_EGL_WINDOW mGdkWindow 7f802d4a6280 returned mEGLWindow 7f8026d7dd00
86625> [Parent 86625: Main Thread]: D/Widget [7f802d9f6000]: nsWindowWayland::CreateNative()
86625> [Parent 86625: Main Thread]: D/Widget nsAppShell::UpdateAndGetSessionState(): session restore enabled, restoring...
86625> [Parent 86625: Main Thread]: D/Widget nsAppShell::GetSessionState() state 1
86625> [Parent 86625: Main Thread]: V/Widget [7f802d9f6000]:   mWaitingToSessionRestore 1
86625> [Parent 86625: Main Thread]: D/Widget [7f802d9f6000]: nsWindowWayland::ConfigureToplevelWindow() register callback for toplevel GdkWindow [7f802d4a58c0]
86625> [Parent 86625: Main Thread]: D/Widget [7f802d9f6000]:   quit, missing gtk3 support!
86625> [Parent 86625: Main Thread]: D/Widget [7f802d9f6000]:   nsWindow type 0
86625> [Parent 86625: Main Thread]: D/Widget [7f802d9f6000]:   mShell 7f802d94dd60 (window 7f802d4a58c0) mContainer 7f8026d88da0 mGdkWindow 7f802d4a6280 XID 0x0
86625> [Parent 86625: Main Thread]: V/Widget [7f802d9f6000]: nsWindow::FractionalScaleFactor(): fractional scale 1.75
86625> [Parent 86625: Main Thread]: D/Widget [7f802d9f6000]: nsWindow::SetCustomTitlebar() State 1 mGtkWindowDecoration 1
86625> [Parent 86625: Main Thread]: D/Widget [7f802d9f6000]:     Using CSD mode
86625> [Parent 86625: Main Thread]: D/Widget [7f802d9f6000]: nsWindowWayland::ConfigureToplevelWindow() register callback for toplevel GdkWindow [7f802d4a65c0]
86625> [Parent 86625: Main Thread]: D/Widget [7f802d9f6000]:   quit, missing gtk3 support!

That doesn't seem right. I think what's going on is:

• In the chrome_debugger_profile, for some reason, I have session-restore enabled. I think that comes from this code which copies pref from the default profile.
• We see session restore is enabled and basically wait for it to finish here
• But session restore never comes because we're not launching the browser, so we just sit it out.

I can reproduce this on a local build by:

• Launching the browser.
• Go to about:settings and enable session restore.
• Launch the browser toolbox. It should work.
• Close both windows.
• Go to objdir/tmp/profile-default/chrome_debugger_profile/prefs.js and add user_pref("browser.startup.page", 3);.
• Try to open the toolbox again. It no longer works.

Martin, it seems we should make that code a bit more solid? I'm not sure why we hit the "missing gtk3 support" in the toolbox process either. But in any case it seems we should probably have some sort of timeout after which we proceed?

Comment 11

[Vlad Zahorodnii [:zzag]]

Emilio, if it's session restore, then it sort of explains why you've started seeing the issue after updating to 6.7. We enabled the session management protocol in 6.7.

Comment 13

[Wayne Mery (:wsmwk)]

Any possibility there could be a Windows issue as well? Reported in screen shot at https://support.mozilla.org/en-US/questions/1589353?page=2#answer-1830069 - unable to get to the performance profiler.

Comment 14

[Emilio Cobos Álvarez [:emilio]]

No, pretty unlikely to be the same

Comment 15

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

(In reply to Emilio Cobos Álvarez [:emilio] from comment #10)

• In the chrome_debugger_profile, for some reason, I have session-restore enabled. I think that comes from this code which copies pref from the default profile.
• We see session restore is enabled and basically wait for it to finish here
• But session restore never comes because we're not launching the browser, so we just sit it out.

What you see is missing https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/9852 in your Gtk3 build.
That's also reason why it's disabled - it can't work without it. So the correct fix here is to make sure session-restore is disabled.

As Gtk3 releases new version once per year, I expect distros will ship local patch then then it can enable it. We may also check the signal presence along with the pref and enable it only when the signal is here.

Comment 16

[BugBot [:suhaib / :marco]]

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

Comment 17

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

Attachment: Bug 2050687 [Wayland] Check xdg-toplevel-realized GtkWidget signal before session restore is enabled r?emilio

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/43a5bf8fc60c
https://hg.mozilla.org/integration/autoland/rev/14f199100a38
[Wayland] Check xdg-toplevel-realized GtkWidget signal before session restore is enabled r=emilio

Comment 19

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/14f199100a38

Comment 20

[BugBot [:suhaib / :marco]]

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

Comment 21

[Mr Beedell, Roke Julian Lockhart [:B.RJL]]

Attachment: A Reproduction Of The Problem

This appears to have reproduced in firefox-nightly-155.0a1-20260724215355.

Comment 22

[Emilio Cobos Álvarez [:emilio]]

This works for me now, can you file another bug?

Comment 23

[Mr Beedell, Roke Julian Lockhart [:B.RJL]]

File another, or re-open my id=2051153#c5? I ask because MOZ_ENABLE_WAYLAND=0 firefox-nightly continues to resolve this, so perhaps that was erroneously triaged as a duplicate of this in the first place.