1751314 - Crash in [@ -[GeckoNSApplication reportException:]] with "NSInvalidArgumentException: -[NSScreen safeAreaInsets]: unrecognized selector sent to instance"

Status: RESOLVED WORKSFORME

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

Description

[Andrew McCreight [:mccr8]]

Crash report: https://crash-stats.mozilla.org/report/index/2e30700a-f3ee-41ad-b067-3b1f50220114

MOZ_CRASH Reason: MOZ_CRASH(Uncaught Objective C exception from -[GeckoNSApplication reportException:])

There are some older crashes that look like this, but there's a more recent spike in crashes, maybe starting in the 20220112095252 build.

Top 10 frames of crashing thread:

0 XUL -[GeckoNSApplication reportException:] widget/cocoa/nsAppShell.mm:152
1 AppKit -[NSApplication run] 
2 None @0xa24a80011b2d1a30 
3 XUL nsAppShell::Run widget/cocoa/nsAppShell.mm:797
4 XUL XREMain::XRE_mainRun toolkit/xre/nsAppRunner.cpp:5348
5 XUL XREMain::XRE_main toolkit/xre/nsAppRunner.cpp:5533
6 XUL XRE_main toolkit/xre/nsAppRunner.cpp:5592
7 firefox main browser/app/nsBrowserApp.cpp:395
8 None @0x0000000104b410f0 
9 None @0x0000000104b410f0 

NSInvalidArgumentException: -[NSScreen safeAreaInsets]: unrecognized selector sent to instance 0x10d0084c0

There are a few comments on crashes:

"Pressing full screen makes the browser crash."

"tried to enter fullscreen mode on macOS 12.0 and it crashed when ╎ clicked the maximize button."

Comment 1

[Andrew McCreight [:mccr8]]

I'm not sure if this is really a regression, but it seems to have started happening much more frequently on 98 Nightly. I see a few crashes on older branches when I looked at the last 3 months.

Comment 2

[Stephen A Pohl [:spohl]]

As of the landing of bug 1748640, this should be guarded behind a pref now, but this is caused by this line. See this comment for an explanation what we should be doing instead.

Comment 3

[Emilio Cobos Álvarez (:emilio)]

But I'm confused, wouldn't that mean that the @available check won't work and we shouldn't hit that line? Or is the available check just ignored?

Comment 4

[Markus Stange [:mstange]]

Yeah it's weird. The failure mode would be "the if isn't entered, even if we are on macOS 12". Not the reverse.
But this crash report is from macOS 12! So the API should definitely be available.
The only other explanation I can see is use-after-free, but I see no reason for the NSScreen object to just disappear here.

Comment 5

[Emilio Cobos Álvarez (:emilio)]

The docs say it's available from macOS 12.0+ but... Maybe there's some pre-release macOS version where it wasn't or something? Otherwise I don't know.

Comment 6

[Stephen A Pohl [:spohl]]

Sorry, I jumped the gun here. I was going to suggest that we use respondsToSelector in addition to the @available check. However, there are other instances where we use APIs that should be fully supported, for example +[NSEvent isSwipeTrackingFromScrollEventsEnabled] which is supported on macOS 10.7+, yet we're still seeing crashes with this API call on the top one or two frames, see crash data here. We used to use respondsToSelector to check for the availability of this instance method, but that never fully addressed or prevented the crashes either.

Maybe we can give this a shot and see if this changes anything?

Comment 7

[Pascal Chevrel:pascalc (PTO until Sept 2)]

I am not seeing recent crashes with this signature, marking as fix-optional for 98.

Comment 8

[Marco Castelluccio [:marco]]

Stephen, given that it looks like this is not happening anymore, could we close the bug or reassess its severity?

Comment 9

[Stephen A Pohl [:spohl]]

This is a recent crash in 101.0a1:

https://crash-stats.mozilla.org/report/index/7f511caa-cb65-4555-a3f7-140700220408

Comment 10

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

Closing because no crashes reported for 12 weeks.