1716114 - Firefox 89.0 consistently crashes when I hover over toolbar extension icons (xfce, intel, egl, no gpu process)

Status: RESOLVED DUPLICATE of bug 1740800

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

Description

[Peter Molnar]

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

Steps to reproduce:

Hovered over any extension icon on the toolbar next to the search bar.

Actual results:

Firefox crashed and brought up the send report dialogue.

Expected results:

Firefox should have continued working.

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'WebExtensions::Untriaged' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Alex Cornestean]

Hello,

I could not reproduce the issue on the latest Nightly (91.0a1/20210613214113), Beta (90.0b7/20210613190011) and Release (89.0/20210527174632) under Windows 10 x64 and Ubuntu 16.04 LTS.

I’ve attempted reproduction using Firefox Multi-Account Containers, uBlock Origin and Dark Reader and hovering over the toolbar icons. No crashes occurred.

Would you mind telling us which extensions you have installed when you noticed this behavior? Do these crashes occur while hovering over specific add-on icons and/or when browsing specific webpages?

Comment 3

[Peter Molnar]

I'm on Debian Stable with any upgrades from backports installed, XFCE as desktop manager, with the x64 Firefox 89 downloaded from mozilla.org.

List of active extensions:

• ClearURLs
• Feedbro
• Forget me not
• h264ify
• Privacy Redirect
• uBlock Origin
• Wallabagger

The only special setting in about:config was disabling disk cache, and I've tried the settings for X11 hardware media acceleration as described in https://wiki.archlinux.org/title/Firefox#Hardware_video_acceleration but the problems occurred with and without those settings fiddled with.

I'm aware that I might have hit some obscure and specific circumstances.

Comment 4

[Rob Wu [:robwu]]

Could you share the crash report (see about:crashes) and the output of about:support?

Comment 5

[Peter Molnar]

https://crash-stats.mozilla.org/report/index/dfe7d54f-1997-4aff-ace8-1c83e0210614

Comment 6

[Peter Molnar]

cli output:

(firefox:341579): Gdk-ERROR **: 15:42:54.795: The program 'firefox' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadDrawable (invalid Pixmap or Window parameter)'.
(Details: serial 2710 error_code 9 request_code 154 (DRI2) minor_code 8)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the GDK_SYNCHRONIZE environment
variable to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
ExceptionHandler::GenerateDump cloned child 341970
ExceptionHandler::WaitForContinueSignal waiting for continue signal...
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Failed to open curl lib from binary, use libcurl.so instead

Comment 7

[Peter Molnar]

Attachment: about:support output

about:support output:

Comment 8

[Rob Wu [:robwu]]

(In reply to Peter Molnar from comment #5)

https://crash-stats.mozilla.org/report/index/dfe7d54f-1997-4aff-ace8-1c83e0210614

Thanks. Crash is initiated via Firefox code at https://searchfox.org/mozilla-central/rev/bea2345ce636dc329ac7133fc0a13c9171777e40/widget/gtk/nsWindow.cpp#3069. From your crash report:

Reason: SIGTRAP

Top 10 frames of crashing thread:

0 libglib-2.0.so.0 _g_log_abort ./debian/build/deb/../../../glib/gmessages.c:557
1 libglib-2.0.so.0 g_log_writer_default ./debian/build/deb/../../../glib/gmessages.c:2688
2 libglib-2.0.so.0 g_log_structured_array ./debian/build/deb/../../../glib/gmessages.c:1896
3 libglib-2.0.so.0 g_log_structured_standard ./debian/build/deb/../../../glib/gmessages.c:1980
4 libgdk-3.so.0 _gdk_x11_display_error_event ./debian/build/deb/gdk/x11/../../../../../gdk/x11/gdkdisplay-x11.c:2769
5 libgdk-3.so.0 gdk_x_error ./debian/build/deb/gdk/x11/../../../../../gdk/x11/gdkmain-x11.c:269
6 libX11.so.6 _XError ./build/src/../../src/XlibInt.c:1444
7 libX11.so.6 handle_error ./build/src/../../src/xcb_io.c:199
8 libX11.so.6 handle_response ./build/src/../../src/xcb_io.c:324
9 libX11.so.6 _XEventsQueued ./build/src/../../src/xcb_io.c:344

Comment 9

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

Is that 89 only or do you see that with 88 too? It may be related to enabled WebRender, can you try to disable it [1]?
[1] https://fedoraproject.org/wiki/How_to_debug_Firefox_problems?rd=Bug_info_Firefox#Check_WebRender

Also do you see any Gtk related message on terminal, like:

(Gecko:30558): Gdk-CRITICAL **: gdk_window_get_origin: assertion `GDK_IS_WINDOW (window)' failed

or so?

Comment 10

[Peter Molnar]

Yes, I did see it with 88, and YES! Disabling Webrender fixed it.

Comment 11

[Darkspirit]

Do you have compositing disabled or is it enabled? (Applications > Settings > Window manager tweaks > Compositing).

Comment 12

[Peter Molnar]

It is enabled. (Sorry for the delay in answering.)

Comment 13

[Darkspirit]

(In reply to Peter Molnar from comment #12)

It is enabled. (Sorry for the delay in answering.)

Does still problem still occur if you reenable WebRender?
Can it be fixed by setting gfx.x11-egl.force-enabled=false, gfx.x11-egl.force-disabled=true and restarting Firefox?

Comment 14

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

This may be fixed by Bug 1730533 where we propagate new XWindow to EGL when it changes. Right now we set XWindow only once when nsWindow is created and we don't update it when it's changed (window is show/hidden/reparent etc.).

Comment 15

[Darkspirit]

(In reply to Peter Molnar)
If you still have the same X11 setup: Does the output of $ xrandr --listproviders contain "Intel" or "modesetting"?

Comment 16

[Peter Molnar]

now it's

$ xrandr --listproviders
Providers: number : 1
Provider 0: id: 0x49 cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 4 outputs: 6 associated providers: 0 name:Intel

but I'm not sure if that was the same during the time I tested 89.0.

Comment 17

[Darkspirit]

Thanks!

(In reply to Peter Molnar from comment #10)

Yes, I did see it with 88, and YES! Disabling Webrender fixed it.

Please force-enable WebRender (set gfx.webrender.software=false, layers.acceleration.disabled=false, gfx.webrender.all=true and restart Firefox)
to check if you can still reproduce this crash.

(In reply to Peter Molnar from comment #16)

Provider 0: id: 0x49 cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 4 outputs: 6 associated providers: 0 name:Intel

Hardware rendering is now (bug 1710400) disabled by default for your setup because you are using the deprecated Intel DDX driver.
That's when $ xrandr --listproviders contains "Intel" instead of the default and recommended "modesetting".
Some users manually choose this driver to use a legacy in-driver compositor to prevent tearing. It's recommended to use a regular X11 compositor instead. If the performance of uncomposited X11 is desired with a compositor, Wayland is recommended.
Please remove deprecated Driver "intel" from your custom Xorg config file and reboot. Does the crash still occur afterwards?