https://codereview.chromium.org/1270663002 is certainly a possibility for this.  I haven't had a chance to look yet.

CC'ing Nick as FYI, since he's been looking at related renderer kills.  (This one is RDH_ILLEGAL_ORIGIN, and Nick is looking at RFMF_GET_COOKIES_BAD_ORIGIN.)  I'll probably just need to install and figure why the renderer is getting killed.

Devlin, this turns out to be a case where uninstalling an app might not close the tab if the tab has a beforeunload handler.  As a result, we kill the renderer if it tries to do an XHR after uninstall, due to the check we added in  issue 513502 .

I've attached a minimal repro case.
1) Unzip and install the attached beforeunload-xhr-app.zip as an unpacked extension, via chrome://extensions.
2) Launch its index.html via chrome://apps.
3) On chrome://extensions in a separate tab, disable the app.
4) Click on "Stay" when the beforeunload dialog appears.
5) Click the XHR button.
The renderer process is killed.

I think we want to enforce that these tabs get closed on uninstall, right?  There's a WebContentsDelegate::ShouldSuppressDialogs that we force to return true to bypass beforeunload when uninstalling an extension/app.  Would you know how to write that code and test?  (It's been a while since I've touched the extension code.)

If not, feel free to assign back to me or another owner.

Deleted: beforeunload-xhr-app.zip 1.3 KB

beforeunload-xhr-app.zip 1.3 KB Download

We understand now that the RFMF_GET_COOKIES_BAD_ORIGIN kill is due to the SecurityStateMap not having an entry for the process in question (we suspect, but have not confirmed, that it's a process shutdown race). The RDH_ILLEGAL_OPERATION check also has a similar 'return false' codepath.

I think the lesson here is to be sure we understand exactly *why* policy->CanCommitURL is returning false, as the answer could surprise you.

Comment 5: Thanks.  That will likely affect this case as well, but we also have a known set of repro steps for the kill without the shutdown race.  Hopefully we can fix the shutdown race independently of this bug?

Devlin: Do you have any ideas on comment 4, or who might be able to help?  We just need a WebContentsDelegate to return true from ShouldSuppressDialogs if a tab has an extension page that is being disabled/uninstalled.

To me this looks like a dupe of  issue 531378 , which I investigated and never got around to actually fixing (but has a bit more context and handy code links in the bug).

Good to merge into that one?

Sure.  I'd forgotten about that one when writing up comment 4.  Sounds like there's more than just suppressing the dialog involved in fixing it properly.