There's a few different points here.  On the one hand, it is unfortunate to penalize the extension for something that, in theory, isn't its own doing.  On the other, we prompt the user when the extension crashes to re-enable, so when the user chooses *not* to re-enable, that's a signal as well.  Re-enabling automatically based on certain heuristics is an interesting thought, but could potentially still be too noisy if the heuristics aren't right.  James, any thoughts?  Also +lazyboy who's looked at a few of these crashes and who's had experience with auto-reenabling extensions.

Automatic heuristic-based re-enabling sounds interesting, but to Devlin's point, I imagine it could be tricky to get right, especially given that some portion of users likely choose not to re-enable the extension right after it crashes.

Perhaps it would be worth teasing out what the heuristics might look like?

Yes, it's true that it's slightly confusing to ask the user and then re-enable it anyway, though that's already the case today. The extension is re-enabled when the user restarts Chrome even if they chose not to re-enable when the bubble is shown. Also, I should point out that the wording is "reloading" not "re-enabling", and that carries less weight and I think makes it clear that the extension may be reloaded automatically at a later time.

The problem with the bubble is that
1) The user might miss it entirely
2) It's much easier to just not do anything even if re-enabling is in the user's favor.

I wonder if one easy way to fix this is to relax the wording on the bubble, to allow a more liberal strategy for re-enabling.
Maybe instead of:
"<extension> has crashed. Click this balloon to reload the extension."
we can say:
"<extension> has crashed. Click this balloon to reload the extension now."

Some ideas for the heuristic:
1) Since users don't restart chrome as often, we should do an exponential backoff that is time based. After first crash, enable after 10 minutes. After second crash enable after 1 day. Third crash, 2 days... and so on.

2) Reload extension for domains that the extension interacts with. The Google Docs Offline extension is an integral part of Docs and Drive. It mentions those domains in both content_capabilities and externally_connectable properties. So if the user visits sites with that domain, Chrome should take that as a signal that it's important to reload the extension. If it was doing a time-based backoff, it should immediately reload the extension. Reloading on page visit should also be throttled and have a backoff, to avoid crash loops.

Note of the balloon notification:
Not every crash needs a user notification: E.g: if the user did not click the balloon the first time, it might make sense to reload the extension, and not show the balloon if the extension crashes. Remember that the extension is just relying on Chrome here and has very little control over chrome crashes.

 Issue 897061  has been merged into this issue.

This would still probably be nice.  We also do this for enterprise policy extensions that need to remain enabled.  With exponential backoff, it shouldn't be *too* much of a risk.  One concern is that we should still have some user-visible indication that an extension crashed - maybe changing the bubble to say "Extension XYZ crashed and was restarted." or similar.

I see extensions crashing often a dozen or more times a day. Security Extensions have crashed while I was away from the browser... leaving me clueless as to the potential security risk; I only realized it after ads began re-appearing, and saw 5-6 security extensions had crashed.

An option to auto-restart extensions just makes sense. 

If all icons have been hidden in the browser, users have no way of knowing if security extensions (or any extension) has crashed, if they are away from their browser. This can pose a serious security risk.

If there is a concern that crashes could re-occur multiple times, or some other issue causing some kind of memory issue, simply make it detect the time and only allow auto-reloading 3 times within a specific time frame, then warn the user "extension reload failed." I'd recommend reloading it as soon as possible. minutes and days makes absolutely no sense.

This bug was targeted to be fixed in 72 release, I notice this particular post has been fermenting for over a year, please re-target this bug.

If the re-enable heuristic has a limit, could we show the notification when the limit is reached? Ideally a permanent notification that needs to be interacted with before hiding?