This dialog doesn’t look polished, the choices it gives don’t seem Apple-like, and the terminology definitely doesn’t match their style.

This may be something that they turn on for beta and then drop for public release.

(disassembling…)

It looks like setting the NSApplicationCrashOnExceptions key to YES via NSUserDefaults will allow us this to just crash without any UI.

https://codereview.chromium.org/2112553009

I don’t think that this is 10.12-specific, it’s probably Apple seed build-specific. It looks like support for showing exceptions in this way goes back at least as far as 10.9.5, but it’s off by default except in 10.12dp1 (I didn’t look at any other seed versions).

-[NSApplication reportException:] pseudocode:

bool GetUserDefault(NSString* key, bool default);

{
  NSLog(@"%@", [exception description]);
  NSLog(@"%@", [exception callStackSymbols]);
  if (GetUserDefault(@"NSApplicationCrashOnExceptions", CRASH_DEFAULT)) {
    // CRASH_DEFAULT is false on 10.9.5, 10.10.5, and 10.12dp1. On 10.11.5,
    // it is true when linked against the 10.11 SDK or later, false
    // otherwise.
    [self crashOnException:exception];  // basically __builtin_trap()
  }
  if ([self _canShowExceptions]) {
    // -[NSApplication -canShowExceptions] is implemented as
    // GetUserDefault(@"NSApplicationShowExceptions", SHOW_DEFAULT) &&
    //     !__NXIsBackgroundOnly()
    // SHOW_DEFAULT is true on 10.12dp1 and false on 10.9.5, 10.10.5, and
    // 10.11.5.
    [self showException:exception];
  }
}

10.9.5 = 13F1712
10.10.5 = 14F1509
10.11.5 = 15F35
10.12dp1 = 16A201w

I suspect that Apple set SHOW_DEFAULT to true for the seed build, and set CRASH_DEFAULT to false (instead of making it follow the SDK as it did in 10.11) for the seed build so that SHOW_DEFAULT would have an opportunity to be used.

Regardless, we can provide our own value for NSApplicationCrashOnExceptions to force things to crash quickly and without extra UI that gives the user the option to continue, which we don’t want. This does not impact the ReportCrash UI, which will still show up to deal with the crash in cases where it would normally (for non-background processes).

NSApplicationShowExceptions goes back to 10.7.

https://developer.apple.com/library/mac/releasenotes/AppKit/RN-AppKitOlderNotes/#X10_7Notes

> NSApplication
>
> AppKit now has the ability to report uncaught exceptions. It is
> controlled by a user default: NSApplicationShowExceptions (YES/NO). The
> default shipping value is NO. In general, it is recommend that developers
> set it to YES during development to catch programming errors. Individual
> applications can automatically turn this on by using [[NSUserDefaults
> standardUserDefaults] registerDefaults: ...] to register the option on.
> It can be set with defaults via: 'defaults write com.yourdomain.app
> NSApplicationShowExceptions YES'. It can also globally be turned on by
> writing to the global domain.

NSApplicationCrashOnExceptions was also introduced in 10.7.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b296d953fe840f3cdf609bde2dc3de53baabae63

commit b296d953fe840f3cdf609bde2dc3de53baabae63
Author: mark <mark@chromium.org>
Date: Fri Jul 01 22:04:43 2016

mac: Crash on uncaught Objective-C exceptions routed to NSApplication

-[NSApplication reportException:] accepts an NSException* which it
logs via NSLog(), and then takes one of these actions:
 1. Immediate intentional crash.
 2. Swallow the exception and return.
 3. Show a dialog that lets the user choose between 1 and 2.

The only option that makes sense to Chrome is (1), an immediate
intentional crash, which can be achieved by setting the
NSApplicationCrashOnExceptions user default to YES. Do this early in
application startup.

BUG= 624885 

Review-Url: https://codereview.chromium.org/2112553009
Cr-Commit-Position: refs/heads/master@{#403545}

[modify] https://crrev.com/b296d953fe840f3cdf609bde2dc3de53baabae63/chrome/browser/chrome_browser_main_mac.mm
[modify] https://crrev.com/b296d953fe840f3cdf609bde2dc3de53baabae63/content/app/mac/mac_init.mm

Your change meets the bar and is auto-approved for M53 (branch: 2785)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/04a5635ba9f304e4dcbaeb11d42175573988d25b

commit 04a5635ba9f304e4dcbaeb11d42175573988d25b
Author: Mark Mentovai <mark@chromium.org>
Date: Fri Jul 08 20:58:03 2016

mac: Crash on uncaught Objective-C exceptions routed to NSApplication

-[NSApplication reportException:] accepts an NSException* which it
logs via NSLog(), and then takes one of these actions:
 1. Immediate intentional crash.
 2. Swallow the exception and return.
 3. Show a dialog that lets the user choose between 1 and 2.

The only option that makes sense to Chrome is (1), an immediate
intentional crash, which can be achieved by setting the
NSApplicationCrashOnExceptions user default to YES. Do this early in
application startup.

BUG= 624885 

Review-Url: https://codereview.chromium.org/2112553009
Cr-Commit-Position: refs/heads/master@{#403545}
(cherry picked from commit b296d953fe840f3cdf609bde2dc3de53baabae63)

Review URL: https://codereview.chromium.org/2134863002 .

Cr-Commit-Position: refs/branch-heads/2785@{#61}
Cr-Branched-From: 68623971be0cfc492a2cb0427d7f478e7b214c24-refs/heads/master@{#403382}

[modify] https://crrev.com/04a5635ba9f304e4dcbaeb11d42175573988d25b/chrome/browser/chrome_browser_main_mac.mm
[modify] https://crrev.com/04a5635ba9f304e4dcbaeb11d42175573988d25b/content/app/mac/mac_init.mm

Could someone please help us with steps so that test team can verify the issue.

Thanks.!

There is no way to test this.  Bug 624850  had the testcase (it was a crash at startup on first run when attempting to show the first run UI), but I fixed that bug so it’s no longer a valid test for this bug. We’d need another crash that triggered an Objective-C exception, but I’m not aware of any that can be raised on demand for testing.