Firefox 141.0a1 (2025-06-11) didn't appear when starting with my profile
Categories
(Core :: Widget: Gtk, defect, P1)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr128 | --- | unaffected |
| firefox-esr140 | --- | unaffected |
| firefox139 | --- | unaffected |
| firefox140 | --- | unaffected |
| firefox141 | --- | fixed |
People
(Reporter: matt.fagnani, Unassigned)
References
(Regression)
Details
(Keywords: regression)
Attachments
(3 files)
Steps to reproduce:
I ran Firefox 141.0a1 (2025-06-10) on Wayland in Plasma 6.3.5 in a Fedora 42 KDE installation. I selected Help > About Nightly in the menu bar. I selected Update to Firefox 141.0a1 (2025-06-11) and Restart to update.
Actual results:
Firefox 141.0a1 (2025-06-11) didn't appear after updating when starting with my profile. I tried to start it a few times but the firefox processes appeared to be sleeping, and there was a crashhelper process which didn't appear.
ps aux | grep firefox
matt 17813 2.8 3.8 3274720 294500 ? Sl 18:01 0:03 /home/matt/programs/firefox/firefox-bin
matt 17831 0.0 0.0 55920 7108 ? Sl 18:01 0:00 /home/matt/programs/firefox/crashhelper 17813 17 /tmp/ 18 20
matt 17909 0.0 0.6 269280 47900 ? Sl 18:01 0:00 /home/matt/programs/firefox/firefox-bin -contentproc -parentBuildID 20250611183851 -prefsHandle 0:39741 -prefMapHandle 1:280085 -sandboxReporter 2 -chrootClient 3 -ipcHandle 4 -initialChannelId {fb73f038-b08b-4ba2-a1f7-def7d755db1f} -parentPid 17813 -crashReporter 5 -crashHelperPid 17831 -appDir /home/matt/programs/firefox/browser 1 socket
matt 17931 0.0 0.4 339708 30524 ? S 18:01 0:00 /home/matt/programs/firefox/firefox-bin -contentproc -ipcHandle 0 -signalPipe 1 -initialChannelId {e3b984bb-e70f-4b59-91a2-7e798e51f17a} -parentPid 17813 -greomni /home/matt/programs/firefox/omni.ja -appomni /home/matt/programs/firefox/browser/omni.ja -appDir /home/matt/programs/firefox/browser 2 forkserver
matt 18068 0.0 0.0 231248 2608 pts/1 S+ 18:03 0:00 grep --color=auto firefox
I created a new profile, and Firefox 141.0a1 (2025-06-11) appeared normally when starting with the new profile. So something in my profile might be preventing Firefox 141.0a1 (2025-06-11) from appearing.
The problem didn't happen with Firefox 141.0a1 (2025-06-10), so I used mozregression with my profile. The first bad revisions were two patches for Bug 1971161 to do with Wayland.
[Wayland] Get HDR monitor info
[Wayland] Move system monitor probe to ScreenGetterGtk class
5:14.37 INFO: Narrowed integration regression window from [f66561ba, 1b7c8502] (3 builds) to [36ff3b31, 1b7c8502] (2 builds) (~1 steps left)
5:14.37 INFO: No more integration revisions, bisection finished.
5:14.37 INFO: Last good revision: 36ff3b312a9ef4502b71202b7af3c38a39114f7a
5:14.37 INFO: First bad revision: 1b7c850236412a412c208a06ef51ad7036476d6c
5:14.37 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=36ff3b312a9ef4502b71202b7af3c38a39114f7a&tochange=1b7c850236412a412c208a06ef51ad7036476d6c
Expected results:
Firefox 141.0a1 (2025-06-11) should've appeared normally when started with my profile.
| Reporter | ||
Updated•6 months ago
|
Comment 1•6 months ago
|
||
:stransky, since you are the author of the regressor, bug 1971161, could you take a look?
For more information, please visit BugBot documentation.
| Reporter | ||
Comment 2•6 months ago
|
||
Firefox 141.0a1 (2025-06-11) on XWayland appeared normally when starting with MOZ_ENABLE_WAYLAND=0. When I used WAYLAND_DEBUG=1 Firefox 141.0a1 (2025-06-11) on Wayland with my profile stopped at the same lines like a few runs
...
[3728907.151] {Default Queue} wp_image_description_info_v1#58.done()
[3728907.249] {Default Queue} -> wp_image_description_v1#57.destroy()
[3728907.272] {Default Queue} -> wp_color_management_output_v1#56.destroy()
[3729565.058] {Default Queue} -> wl_compositor#4.create_surface(new id wl_surface#63)
[3729565.813] {Default Queue} -> wl_compositor#4.create_surface(new id wl_surface#64)
[3729566.430] {Default Queue} -> wl_compositor#4.create_surface(new id wl_surface#65)
[3729567.150] {Default Queue} -> wl_compositor#4.create_surface(new id wl_surface#66)
[3729786.174] {Default Queue} -> wl_compositor#4.create_surface(new id wl_surface#67)
I'm attaching the output of a Firefox 141.0a1 (2025-06-11) on Wayland run with WAYLAND_DEBUG=1 which didn't appear. Firefox 141.0a1 (2025-06-11) on Wayland did appear once when I ran it with WAYLAND_DEBUG=1 and -P and selected my profile.
I tried to set some modified graphics parameters in my profile back to the default one at a time, but they didn't fix the problem.
| Reporter | ||
Comment 3•6 months ago
|
||
When the problem happened with Firefox 141.0a1 (2025-06-11) on Wayland using my profile, only two content processes were running according to ps aux | grep firefox. When Firefox 141.0a1 (2025-06-11) on Wayland started normally with the new profile, eight content processes were running. Something might have prevented the content processes 3-8 from starting which led to Firefox not appearing.
I aborted the Firefox 141.0a1 20250611215745 parent process with kill -6 when the problem happened. The crash report was https://crash-stats.mozilla.org/report/index/40233b9f-8e73-4f13-abac-69dc40250612
Comment 4•6 months ago
|
||
Please try to get backtrace / crash ID from frozen Firefox and attach it here:
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems?rd=Bug_info_Firefox#Getting_Mozilla_crash_report_from_running_or_frozen_Firefox
Thanks.
Comment 5•6 months ago
|
||
Can you also run on terminal with MOZ_LOG="WidgetScreen:5" WAYLAND_DEBUG=1 env variables and attach the log here?
Thanks.
Comment 6•6 months ago
|
||
I see the same behavior on Gnome.
Updated•6 months ago
|
Comment 8•6 months ago
|
||
Set release status flags based on info from the regressing bug 1971161
Comment 9•6 months ago
|
||
The bug is marked as tracked for firefox141 (nightly). We have limited time to fix this, the soft freeze is in 7 days. However, the bug still isn't assigned.
:gcp, could you please find an assignee for this tracked bug? Given that it is a regression and we know the cause, we could also simply backout the regressor. If you disagree with the tracking decision, please talk with the release managers.
For more information, please visit BugBot documentation.
Comment 10•6 months ago
|
||
Do you need more data debugging? I was also reproducing this morning
Comment 11•6 months ago
|
||
Bug 1971161 was backed out, so no need to track.
| Reporter | ||
Comment 12•6 months ago
|
||
I submitted a crash report when the problem happened and I aborted Firefox as I mentioned in Comment 3 https://crash-stats.mozilla.org/report/index/40233b9f-8e73-4f13-abac-69dc40250612
I'm attaching the output with MOZ_LOG="WidgetScreen:5" WAYLAND_DEBUG=1 when the problem happened with 141.0a1 20250611215745
The problem didn't happen with 141.0a1 20250612104024 using my profile. Thanks.
Comment 13•6 months ago
|
||
Interesting, I don't see anything obvious why it may fail. But working on KDE right now to make sure it works fine.
Closing this one as Bug 1971161 was backed out.
Updated•5 months ago
|
Description
•