2013677 - [Wayland] Firefox sometimes crashes when .focus() is called by Taskbar Tabs on Wayland

Status: RESOLVED FIXED

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

Description

[Duncan McIntosh [:dmcintosh]]

I'm working on adding support for Taskbar Tabs/Firefox Web Apps on Linux (bug 1982733), and I'm encountering a fairly frequent crash with Wayland protocol code when TaskbarTabsWindowManager calls win.focus(). I've been able to work around it by making both call sites Windows-only (https://phabricator.services.mozilla.com/D281300), so the test suite can complete, but I'd like to avoid disabling this on Linux.

With the workaround reverted, here's a crash when removing the Taskbar Tab with the page action (which causes focus() to be called on the window it goes to): https://crash-stats.mozilla.org/report/index/9b251051-cd32-4b93-aa70-877d90260130

(It's possible that something else in my stack is doing this, but it's all JavaScript so I'm not sure how that could happen.)

Comment 1

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

Can you please run on terminal with WAYLAND_DEBUG=1 MOZ_LOG="Widget:5" env variables, reproduce the crash and attach the log here? I'd love to fix that as it's Firefox/Wayland bug.
Thanks.

Comment 2

[Duncan McIntosh [:dmcintosh]]

Attachment: focus-crash-20260202a-nonul.log

Here's a log from WAYLAND_DEBUG=1 MOZ_LOG="Widget:5" ./firefox >&2 2>focus-crash-20260202a.log when opening a taskbar tab.

(There were a lot (~1 100 000) of nul bytes near the end? I omitted them, and they came after the crash anyways, if you want the original let me know.)

Comment 3

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

Thanks. Yes, I don't need the null bytes.

But the log looks truncated somehow...can you try to get more logs and also submit / attach crash ID for them? I'd need the crash reason from crash report.
Thanks.

Comment 4

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

From the crash ID you posted first it looks like bug here:

static void
gdk_wayland_window_focus (GdkWindow *window,
                          guint32    timestamp)
{
  GdkWindowImplWayland *impl = GDK_WINDOW_IMPL_WAYLAND (window->impl);
  GdkDisplay *display = gdk_window_get_display (window);
  GdkWaylandDisplay *display_wayland = GDK_WAYLAND_DISPLAY (display);
  gchar *startup_id = NULL;

 [...]

          focus_window = gdk_wayland_device_get_focus (gdk_seat_get_keyboard (seat));
          if (focus_window)
            wl_surface = gdk_wayland_window_get_wl_surface (focus_window);
          if (wl_surface)
            xdg_activation_token_v1_set_surface (token, wl_surface);

but the null wl_surface is checked. I wonder if you use any old gtk3 version or so? But you're report says it's Fedora Linux 43 so it's the same system as I use. May you pass me a reproducer so I can try myself?

Thanks.

Comment 5

[Duncan McIntosh [:dmcintosh]]

I think the crash log I gave you is right, but it includes some Wayland logs from the crash reporter? I think the crash is at line 3506, although I admit it doesn't look like it gives much detail. There was also a console message along the lines of (this one is from crashing just now in gdb):

[GFX1-]: (kde) Wayland protocol error: error marshalling arguments for set_surface (signature o): null value passed for arg 0

Which additional logs would be useful?

It looks to me like the original crash log is failing in RequestWaylandFocusPromise instead of gdk_wayland_window_focus, and RequestWaylandFocusPromise doesn't appear to guard for null in set_surface. I'm not familiar with xdg-activation, but would a guard there be all that's needed?

Not sure what you mean by reproducer, I've submitted a try run for the version I'm using assuming you meant runnable build. (I also submitted a version with the hypothetical null guard added, which I haven't tested locally. I'll give that a shot and let you know if it seems more stable.)

I find I can reproduce it consistently by:

1. Open the patched Firefox.
2. Visit about:config and set browser.taskbarTabs.enabled to true.
3. Go to https://www.wikipedia.org/.
4. Click on the 'Add to taskbar' button in the address bar. (It might crash after.)
5. In the new window, click on the 'Remove from taskbar' button, again in the address bar. (It should crash here.)

Comment 6

[Duncan McIntosh [:dmcintosh]]

Just tried the try builds—I can reproduce the crash with the first one, and the second seems to fix it. If the change seems reasonable (and especially if you can reproduce with the first and not the second) then I can submit a Phabricator revision.

Comment 7

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

(In reply to Duncan McIntosh [:dmcintosh] from comment #6)

Just tried the try builds—I can reproduce the crash with the first one, and the second seems to fix it. If the change seems reasonable (and especially if you can reproduce with the first and not the second) then I can submit a Phabricator revision.

Yes, looks like you've found it! Please create a phabricator revision for it and r? me or emilio.

If gdk_wayland_window_get_wl_surface(gdkWindow) returns nullptr just quit - the window is not visible so there's no point to try to transfer the focus anyway.

Thanks.

Comment 8

[Duncan McIntosh [:dmcintosh]]

Attachment: Bug 2013677 - Return early from RequestWaylandFocusPromise if the surface is null. r=stransky

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/4b4de6409e36
https://hg.mozilla.org/integration/autoland/rev/d60ca9348c81
Return early from RequestWaylandFocusPromise if the surface is null. r=stransky

Comment 10

[Silaghi Andreea]

https://hg.mozilla.org/mozilla-central/rev/d60ca9348c81