The first run dialog on Mac has no cancel button, and the Quit menu item is disabled. The reasons for this are subtle:

The code currently creates a nested RunLoop to invoke [NSApp runModalForWindow:], because of  Issue 54248 . That issue seems like it might be obsolete right now; if I remove the nested RunLoop construction and the matching MessageLoop::QuitNow(), everything still seems to work alright, including quitting the browser. The problem originally mentioned in 54248 (needing the message loop to show search engines) *might* be obsolete now, or else the original problem with MessageLoop::Run() breaking [NSApp runModalForWindow:] may have vanished.

I experimented with adding a cancel button to the First Run dialog, which would have the semantics of "re-do the first run experience at next launch". There are two issues:

1) The "first run happened" sentinel is already created by this point, so exiting the browser in any way doesn't cause the FRE to re-run. We might be able to move the sentinel creation later in ChromeBrowserMainParts::PreMainMessageLoopRunImpl() to deal with that. I need to check if that is safe to do.

2) It doesn't seem possible to cleanly exit the browser from inside PreMainMessageRunLoopImpl. Generally what happens is one of:

a) The browser exits immediately if we call exit(0) or another immediate-death function
b) The browser starts exiting, but posted tasks from PreMainMessageRunLoopImpl run before the exit task does, and they explode because they are not happy with being run while the browser is shutting down. This happens if we call [NSApp terminate:].
c) The browser does not exit, and later attempts to exit it do nothing, possibly because the browser already thinks it is exiting. This happens if we call chrome::AttemptExit(), g_browser_process->EndSession(), or any of the other likely-seeming "orderly exit" functions.

Case (a) works, but it seems extremely dangerous to unceremoniously exit like this when other tasks may be in flight. Case (b) causes an immediate crash. Case (c) breaks exiting the browser. :(

Future investigation:
* Is case (a) actually dangerous?
* For case (b), there is a comment in PreMainMessageRunLoopImpl like this:

  // TODO(stevenjb): Move WIN and MACOSX specific code to appropriate Parts.
  // (requires supporting early exit).

This suggests that early exit from inside PreMainMessageRunLoopImpl is not supported. How hard would it be to support it? If we could support that, the first run dialog code could return a status to indicate that the caller should early-exit the browser.
* For case (c), why does the browser not exit immediately or afterward?
* Did the problem mentioned in  Issue 54248  actually vanish?