1870924 - Crash in [@ nsMenuBarX::Paint] in headless Firefox

Status: RESOLVED FIXED

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

Description

[Max Schmitt]

Steps to reproduce:

Upload a file via a headless browser (Playwright).

Actual results:

In the case of headless AppWindow::GetMainWidget returns a HeadlessWidget instead of a CocoaWindow (compared to headed). We expect a CocoaWindow tho and then try to cast a HeadlessWidget into a CocoaWindow which segfaults later on in the Paint() method.

Proposed solution: Check if its headless here and then return a nullptr since there is no CocoaWindow for it.

Stack:

Note: nsMenuBarX::Paint(this=0x0000000000000001) this is 0x1 because we wrongly cast and then it messes up Paint().

frame #0: 0x000000010fd7b7d4 XUL`nsMenuBarX::Paint(this=0x0000000000000001) at nsMenuBarX.mm:433:4 [opt]
frame #1: 0x000000010fd7b660 XUL`nsCocoaUtils::PrepareForNativeAppModalDialog() at nsCocoaUtils.mm:342:24 [opt]
frame #2: 0x000000010fd8d3f8 XUL`nsFilePicker::GetLocalFiles(this=0x000000012b72e700, inAllowMultiple=<unavailable>, outFiles=0x000000012b72e768) at nsFilePicker.mm:315:3 [opt]
frame #3: 0x000000010fd8d1a8 XUL`nsFilePicker::Show(this=0x000000012b72e700, retval=0x000000016fcd8456) at nsFilePicker.mm:0:3 [opt]
frame #4: 0x000000010fd1d52c XUL`nsBaseFilePicker::AsyncShowFilePicker::Run(this=0x000000013d6e5220) at nsBaseFilePicker.cpp:86:32 [opt]
frame #5: 0x000000010d0c6224 XUL`mozilla::RunnableTask::Run(this=0x000000013022fc40) at TaskController.cpp:549:16 [opt]
frame #6: 0x000000010d0c3894 XUL`mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal(this=0x0000000100c0be40, aProofOfLock=<unavailable>) at TaskController.cpp:876:26 [opt]
frame #7: 0x000000010d0c2aa8 XUL`mozilla::TaskController::ExecuteNextTaskOnlyMainThreadInternal(this=0x0000000100c0be40, aProofOfLock=0x000000016fcd85e0) at TaskController.cpp:699:15 [opt]
frame #8: 0x000000010d0c8684 XUL`mozilla::detail::RunnableFunction<mozilla::TaskController::TaskController()::$_0>::Run() [inlined] mozilla::TaskController::ProcessPendingMTTask(this=0x0000000100c0be40, aMayWait=false) at TaskController.cpp:485:36 [opt]
frame #9: 0x000000010d0c866c XUL`mozilla::detail::RunnableFunction<mozilla::TaskController::TaskController()::$_0>::Run() [inlined] mozilla::TaskController::TaskController()::$_0::operator()(this=<unavailable>) const at TaskController.cpp:211:37 [opt]
frame #10: 0x000000010d0c8664 XUL`mozilla::detail::RunnableFunction<mozilla::TaskController::TaskController()::$_0>::Run(this=<unavailable>) at nsThreadUtils.h:548:5 [opt]
frame #11: 0x000000010d0d4fb0 XUL`nsThread::ProcessNextEvent(this=0x000000010c96a620, aMayWait=<unavailable>, aResult=0x000000016fcd8707) at nsThread.cpp:1198:16 [opt]
frame #12: 0x000000010d0d3138 XUL`NS_ProcessPendingEvents(aThread=0x000000010c96a620, aTimeout=10) at nsThreadUtils.cpp:445:19 [opt]
frame #13: 0x000000010fd13f5c XUL`nsBaseAppShell::NativeEventCallback(this=0x000000011ceb25c0) at nsBaseAppShell.cpp:87:3 [opt]
frame #14: 0x000000010fd778c8 XUL`nsAppShell::ProcessGeckoEvents(aInfo=0x000000011ceb25c0) at nsAppShell.mm:537:11 [opt]
frame #15: 0x0000000185c87a4c CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28
frame #16: 0x0000000185c879e0 CoreFoundation`__CFRunLoopDoSource0 + 176
frame #17: 0x0000000185c87750 CoreFoundation`__CFRunLoopDoSources0 + 244
frame #18: 0x0000000185c86340 CoreFoundation`__CFRunLoopRun + 828
frame #19: 0x0000000185c859ac CoreFoundation`CFRunLoopRunSpecific + 608
frame #20: 0x0000000190234448 HIToolbox`RunCurrentEventLoopInMode + 292
frame #21: 0x0000000190234284 HIToolbox`ReceiveNextEventCommon + 648
frame #22: 0x0000000190233fdc HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 76
frame #23: 0x00000001894628a4 AppKit`_DPSNextEvent + 660
frame #24: 0x0000000189c3c980 AppKit`-[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 716
frame #25: 0x000000010fd76ec8 XUL`-[GeckoNSApplication nextEventMatchingMask:untilDate:inMode:dequeue:](self=0x0000000100c650c0, _cmd=<unavailable>, mask=18446744073709551615, expiration=4001-01-01 00:00:00 UTC, mode="kCFRunLoopDefaultMode", flag=YES) at nsAppShell.mm:190:24 [opt]
frame #26: 0x0000000189455d50 AppKit`-[NSApplication run] + 476
frame #27: 0x000000010fd77f40 XUL`nsAppShell::Run(this=0x000000011ceb25c0) at nsAppShell.mm:867:5 [opt]
frame #28: 0x0000000110e89d6c XUL`nsAppStartup::Run(this=0x000000011e36aed0) at nsAppStartup.cpp:296:30 [opt]
frame #29: 0x0000000110f5cd6c XUL`XREMain::XRE_mainRun(this=0x000000016fcd9f60) at nsAppRunner.cpp:5675:22 [opt]
frame #30: 0x0000000110f5d3cc XUL`XREMain::XRE_main(this=0x000000016fcd9f60, argc=7, argv=0x000000016fcda6f8, aConfig=<unavailable>) at nsAppRunner.cpp:5884:8 [opt]
frame #31: 0x0000000110f5d778 XUL`XRE_main(argc=<unavailable>, argv=<unavailable>, aConfig=<unavailable>) at nsAppRunner.cpp:5940:21 [opt]
frame #32: 0x0000000100124bd4 firefox`main [inlined] do_main(argc=7, argv=0x000000016fcda6f8, envp=<unavailable>) at nsBrowserApp.cpp:227:22 [opt]
frame #33: 0x0000000100124a34 firefox`main(argc=<unavailable>, argv=<unavailable>, envp=<unavailable>) at nsBrowserApp.cpp:445:16 [opt]

Expected results:

Works

Comment 1

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

Max, thank you for the report. Is that a new issue in Firefox 121? I wonder if it is somewhat related to the crash that I see on bug 1871527.

Also at which point in the stack does Playwright hook into Gecko APIs given that it patches various sources? It might help to find the regressor of this issue faster. Thanks.

Comment 2

[Stephen A Pohl [:spohl]]

Attachment: Bug 1870924: Prevent crashes when trying to access the menu bar in headless mode. r=#mac-reviewers

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6f7de1b98bec
Prevent crashes when trying to access the menu bar in headless mode. r=mac-reviewers,bradwerth

Comment 4

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/6f7de1b98bec

Comment 5

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

Max, can you please verify that this change will fix the issue with Playwright's custom Firefox build as well? Thanks.

Comment 6

[Max Schmitt]

Yes according to code it should. We did a similar fix on our side which we'll remove then, which made it work.

Appreciate the quick fix a lot and happy holidays!

Comment 7

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

Thanks.

Stephen, do you think that we should uplift this patch? At least to beta?

Comment 8

[Stephen A Pohl [:spohl]]

Comment on attachment 9370074 [details]
Bug 1870924: Prevent crashes when trying to access the menu bar in headless mode. r=#mac-reviewers

Beta/Release Uplift Approval Request

• User impact if declined: Firefox may crash in headless mode when uploading files.
• 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 return early when trying to retrieve the hidden window's menu bar.
• String changes made/needed: none
• Is Android affected?: No

Comment 9

[Donal Meehan [:dmeehan]]

Comment on attachment 9370074 [details]
Bug 1870924: Prevent crashes when trying to access the menu bar in headless mode. r=#mac-reviewers

Approved for 122.0b5

Comment 10

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/eea23ed30342