sky@, am I right to assume that this is not the desired behavior? Or is there a reason we ignore RestoreOnStartupURLs in that case?

We have had crashes in the past restoring sessions after a crash (e.g. you get stuck in a crash loop). It's possible restoring startup urls could trigger the same behavior.

It seems to me after a crash it's more likely you want to restore the previous session than the startup urls. Another motivation for not launching the startup urls.

I would be inclined to add a button to the crash bubble that lets you launch the startup urls (assuming that is the users pref). But you would have to run that by UX.

On of the main reasons this policy is used is that enterprises want to have their own branding when their users open up Chrome and they find that this particular workflow breaks it.

They would have been OK with restoring automatically but we don't want that, because of the potential crash loop. However, if the crash loop is actually due to a startup page (which would probably be rare as this should be caught on during testing), then this is something they can act on by changing/removing the offending page.

I don't think the enterprise issue should be a particular concern here. Chrome crashed, if Chrome hadn't crashed in the first place the user may not have been seeing the startup pages in the first place (they may have navigated else where).

The problem with a crash loop is that it's devastating, you can't do anything until a fix is released.

I'm still of the opinion the best option is adding another button to the infobar.

With the upcomging NewTabPageLocation policy, Enterprise admins could use it to brand the startup experience, including post-crash (the overridden NTP gets loaded under the crash restore bubble).

I don't mind trying out the extra button suggestion from sky@, I think I can cook it up quickly and then show it to UX to get approval...

Here's the CL with an added button to open startup pages from the crash bubble:
https://codereview.chromium.org/2644663003/

Also started a conversation with chrome-ux to confirm the strings and behaviour.

Chrome UX approved the changed and CL got LGTM, just waiting for OWNER approvals now.

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

commit f82ec0d63125d78d32a38be642350ebc76762b4c
Author: mad <mad@chromium.org>
Date: Thu Jan 26 14:30:16 2017

Offer to open the startup pages after a crash.

BUG= 646834 

TBR=jochen@chromium.org
for minor changes in components_strings.grd
TBR=asvitkine@chromium.org
for minor changes in histograms.xml

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

[modify] https://crrev.com/f82ec0d63125d78d32a38be642350ebc76762b4c/chrome/browser/sessions/session_restore.cc
[modify] https://crrev.com/f82ec0d63125d78d32a38be642350ebc76762b4c/chrome/browser/sessions/session_restore.h
[modify] https://crrev.com/f82ec0d63125d78d32a38be642350ebc76762b4c/chrome/browser/sessions/session_restore_browsertest.cc
[modify] https://crrev.com/f82ec0d63125d78d32a38be642350ebc76762b4c/chrome/browser/ui/startup/startup_browser_creator.cc
[modify] https://crrev.com/f82ec0d63125d78d32a38be642350ebc76762b4c/chrome/browser/ui/startup/startup_browser_creator.h
[modify] https://crrev.com/f82ec0d63125d78d32a38be642350ebc76762b4c/chrome/browser/ui/views/session_crashed_bubble_view.cc
[modify] https://crrev.com/f82ec0d63125d78d32a38be642350ebc76762b4c/chrome/browser/ui/views/session_crashed_bubble_view.h
[modify] https://crrev.com/f82ec0d63125d78d32a38be642350ebc76762b4c/components/components_strings.grd
[modify] https://crrev.com/f82ec0d63125d78d32a38be642350ebc76762b4c/tools/metrics/histograms/histograms.xml