[wlroots] Firefox freezes when some buttons are clicked
Categories
(Core :: Widget: Gtk, defect)
Tracking
()
People
(Reporter: omerfaruko, Unassigned)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: regression)
Attachments
(3 files)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:149.0) Gecko/20100101 Firefox/149.0
Steps to reproduce:
- Create a new profile.
- Search "ublock origin".
- Go to linked Firefox addons site.
- Click on "Add to Firefox" button.
Actual results:
The application freezes and becomes unresponsive. I could exit only with pkill firefox.
Expected results:
It should not freeze. This has started after 148.0.2 -> 149.0.2 update two days ago.
Extra Info: wayland 1.24.0, wlroots 0.19.3
|
||
Comment 1•1 month ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
I received some help in https://chat.mozilla.org/#/room/#firefox:mozilla.org.
Following steps in https://support.mozilla.org/en-US/kb/diagnose-firefox-issues-using-troubleshoot-mode, the issue didn't happen after starting in troubleshoot mode or with -safe-mode both for 151.0a1 and 149.0.2.
Disabling hardware acceleration prevents it from happening without troubleshoot mode: https://support.mozilla.org/en-US/kb/performance-settings
I'll follow up later with https://profiler.firefox.com/
|
||
Comment 7•1 month ago
|
||
Can you use mozregression to fix the broken commit?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Use_Mozregression_tool
Thanks.
First run:
mozregression --good=148 --bad=149
6:44.64 INFO: Last good revision: d154d7fdf800eb1a70ddb2614e2374e63e848ab4
6:44.64 INFO: First bad revision: b75a2a119a6f8f12a218c90dd31e3d91c8f1d985
6:44.64 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=d154d7fdf800eb1a70ddb2614e2374e63e848ab4&tochange=b75a2a119a6f8f12a218c90dd31e3d91c8f1d985
These didn't seem relevant. "good"s are probably flakey. Rerunning:
mozregression --good=148 --bad=b75a2a119a6f8f12a218c90dd31e3d91c8f1d985
9:23.85 INFO: Narrowed integration regression window from [caeb1bb1, 4898d067] (3 builds) to [f9a55c6c, 4898d067] (2 builds) (~1 steps left)
9:23.85 INFO: No more integration revisions, bisection finished.
9:23.85 INFO: Last good revision: f9a55c6cc131183417222cb5d8ef9839c911ca7f
9:23.85 INFO: First bad revision: 4898d067ee28f052f9d1c57ffde37dc0aad68e33
9:23.85 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=f9a55c6cc131183417222cb5d8ef9839c911ca7f&tochange=4898d067ee28f052f9d1c57ffde37dc0aad68e33
This one seems more relevant.
|
|
||
Comment 9•1 month ago
|
||
Looks like a bug in wlroots so better to report there.
|
Reporter | |
Comment 10•1 month ago
|
||
hmm I think I got some rough sketch in my head. IIUC, above change started reusing some buffers in Firefox. This required, among other things, synchronization between nvidia driver & egl-wayland and sway & wlroots to work as prescribed by the relevant wayland protocol, specifically the latter to signal explicitly handing buffers back, which I'm guessing sway & wlroots either don't do or their implementation isn't mature enough yet, hence egl-wayland blocks forever, freezing the main thread.
Anyway, I came across this obscure environment variable __NV_DISABLE_EXPLICIT_SYNC for egl-wayland which turns off more recent explicit syncing protocol. I turned hardware acceleration back on in FF and turned explicit sync off with env __NV_DISABLE_EXPLICIT_SYNC=1 firefox and freezes didn't reproduce so far. I think I'll wait out wlroots 0.20 & sway 1.12 to be available in arch repos and then file a bug against wlroots if it's not solved by then.
TLDR for future readers: Try out env __NV_DISABLE_EXPLICIT_SYNC=1 firefox or turning off hardware acceleration.
Description
•