Closed Bug 1971638 Opened 6 months ago Closed 6 months ago

Firefox 141.0a1 (2025-06-11) didn't appear when starting with my profile

Categories

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

Firefox 141
defect

Tracking

()

RESOLVED FIXED
141 Branch
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.

Keywords: regression
Regressed by: 1971161

:stransky, since you are the author of the regressor, bug 1971161, could you take a look?

For more information, please visit BugBot documentation.

Flags: needinfo?(stransky)

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.

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

Flags: needinfo?(stransky) → needinfo?(matt.fagnani)

Can you also run on terminal with MOZ_LOG="WidgetScreen:5" WAYLAND_DEBUG=1 env variables and attach the log here?
Thanks.

Duplicate of this bug: 1971697
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P1

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

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.

Flags: needinfo?(gpascutto)

Do you need more data debugging? I was also reproducing this morning

Flags: needinfo?(stransky)

Bug 1971161 was backed out, so no need to track.

Flags: needinfo?(gpascutto)

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.

Flags: needinfo?(matt.fagnani)

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.

Status: NEW → RESOLVED
Closed: 6 months ago
Flags: needinfo?(stransky)
Resolution: --- → FIXED
Target Milestone: --- → 141 Branch
See Also: → 1976381
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: