1871527 - Permanent startup crash of Firefox 121 when using "--screenshot" argument [@ nsAutoRefCnt::operator-- | nsCocoaWindow::SetMenuBar(RefPtr<nsMenuBarX>&&)]

Status: VERIFIED FIXED

(Core :: Widget: Cocoa, defect, P2)

Description

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:122.0) Gecko/20100101 Firefox/122.0 ID:20231217210522

Starting with Firefox 121 I can see a permanent startup crash of Firefox when using the --screenshot command. That usually starts Firefox in headless mode, navigates to the supplied web page, and then writes the captured screenshot to a file.

Here an example command that I'm using:

/Applications/Firefox.app/Contents/MacOS/firefox --screenshot http://example.com

Instead of creating the screenshot.png file the following crash appears:

Crash report: https://crash-stats.mozilla.org/report/index/8ae62375-f1e7-4e8b-a474-e24760231222

Reason: EXC_BAD_ACCESS / KERN_INVALID_ADDRESS

Top 10 frames of crashing thread:

0  XUL  nsAutoRefCnt::operator--  xpcom/base/nsISupportsImpl.h:340
0  XUL  nsMenuBarX::Release  widget/cocoa/nsMenuBarX.h:86
0  XUL  mozilla::RefPtrTraits<nsMenuBarX>::Release  mfbt/RefPtr.h:54
0  XUL  RefPtr<nsMenuBarX>::ConstRemovingRefPtrTraits<nsMenuBarX>::Release  mfbt/RefPtr.h:420
0  XUL  RefPtr<nsMenuBarX>::assign_assuming_AddRef  mfbt/RefPtr.h:73
0  XUL  RefPtr<nsMenuBarX>::operator=  mfbt/RefPtr.h:188
0  XUL  nsCocoaWindow::SetMenuBar  widget/cocoa/nsCocoaWindow.mm:2557
1  XUL  mozilla::widget::NativeMenuSupport::CreateNativeMenuBar  widget/cocoa/NativeMenuSupport.mm:24
2  XUL  mozilla::AppWindow::ShowModal  xpfe/appshell/AppWindow.cpp:507
3  XUL  nsWindowWatcher::OpenWindowInternal  toolkit/components/windowwatcher/nsWindowWatcher.cpp:1437

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+1]]

I forgot to mention that there is actually also bug 1870924 which reports crashes with headless mode as well but when using the file picker through automation with Playwright.

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+1]]

The regression range here is:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=189e42190fedcf91fa2b36eaf39947edae73507f&tochange=0be08aa0812f81d5eb9f2235165d8478ebaf825b

And it looks like this is related to bug 1107433 for Add fallback menu bar for early startup modals.

Comment 3

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

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

Comment 4

[Stephen A Pohl [:spohl]]

I'm unable to reproduce the crash locally, but the fix seems straightforward.

Comment 5

[Stephen A Pohl [:spohl]]

Attachment: Bug 1871527: Fix a crash in headless mode due to the creation of native menu bars for modals. r=#mac-reviewers

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/bf93dcd0ace3
Fix a crash in headless mode due to the creation of native menu bars for modals. r=mac-reviewers,bradwerth

Comment 7

[Sandor Molnar[:smolnar]]

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

Comment 8

[Donal Meehan [:dmeehan]]

:sphol could you add an uplift request on this when ready? At least for beta, but release too if it's safe to go in a later dot release.

Comment 9

[Stephen A Pohl [:spohl]]

Comment on attachment 9370050 [details]
Bug 1871527: Fix a crash in headless mode due to the creation of native menu bars for modals. r=#mac-reviewers

Beta/Release Uplift Approval Request

• User impact if declined: Firefox may crash in headless mode.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This patch adds a simple check whether or not we're running in headless mode. If so, we skip one line of code that was introduced in bug 1853230, returning the behavior for headless mode back to what it was prior to the landing of bug 1853230. This is extremely low risk.
• String changes made/needed: none
• Is Android affected?: No

Comment 10

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Thank you for the quick fix! I can verify with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:123.0) Gecko/20100101 Firefox/123.0 ID:20231223095203 that the crash no longer happens.

Comment 11

[Donal Meehan [:dmeehan]]

Comment on attachment 9370050 [details]
Bug 1871527: Fix a crash in headless mode due to the creation of native menu bars for modals. r=#mac-reviewers

Approved for 122.0b4

Comment 12

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/32cf5092b68d

Comment 13

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9370050 [details]
Bug 1871527: Fix a crash in headless mode due to the creation of native menu bars for modals. r=#mac-reviewers

Approved for 121.0.1

Comment 14

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-release/rev/bc8b273ca516

Comment 15

[Bogdan Maris, Desktop QA]

Reproduced the crash using Firefox 121.0 on macOS 13.6, https://crash-stats.mozilla.org/report/index/ed3bb9f1-d315-4091-aafc-a310e0240109.
Verified that using Firefox 121.0.1 and Firefox 122.0b7 with --screenshot argument I don't receive the crash anymore and I have the .png file saved but only on mac 10.15.

If I try to verify the fix on the fixed builds (123.0a1, 122.0b7 and 121.0.1) on macOS 13.6 and 12 I will get the error bellow in the console and I have no screenshot saved although the Firefox process remains active in Activity monitor.

*** You are running in headless mode.
[GFX1-]: RenderCompositorSWGL failed mapping default framebuffer, no dt

Should this be working only in 10.15 (and probably lower) or is there a way to make it work on newer mac versions as well?

Comment 16

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Bogdan, do you have multiple Firefox profiles on the machines running 13.6 and 12? This is most likely bug 1563725 then and you need to specify a profile name on the command line.

Comment 17

[Bogdan Maris, Desktop QA]

(In reply to Henrik Skupin [:whimboo][⌚️UTC+1] from comment #16)

Bogdan, do you have multiple Firefox profiles on the machines running 13.6 and 12? This is most likely bug 1563725 then and you need to specify a profile name on the command line.

That's correct, I did have the profile manager set up to open when starting Firefox. I set it up to just open directly with a profile and seems to work now in macOS 13 as well, no errors in terminal and I can see the .png file saved on drive. Thanks for pointing that out. Marking the bug as verified based on the testing performed.