We need the server crash ID.. Can you provided that?

In Google Chrome Versión 55.0.2880.0 canary (64-bit):

Crashed ID 5044ed97-7ba9-46fc-a79f-1214bc0ce4bd (ID server: 7307403e00000000)

Referenced issue from crash server is  issue 622385 .

alexmos@ it indicates you fixed this. Did it come back?
tkent@ I was able to repro this but had a completely different stack trace on linux. Wonder if forms are causing something weird.

My crash id is 1d7a3fed00000000. I just loaded the file from disk on M53.

Deleted: test.html 107 bytes

test.html 107 bytes View Download

Reproduced on Mac too.

	0x000000010663bd18	(Google Chrome Framework -render_process_host_impl.cc:1443 )	content::RenderProcessHostImpl::ShutdownForBadMessage()
0x00000001064e3e19	(Google Chrome Framework -render_frame_host_impl.cc:1148 )	content::RenderFrameHostImpl::OnDidCommitProvisionalLoad(IPC::Message const&)
0x00000001064e1bc8	(Google Chrome Framework -render_frame_host_impl.cc:603 )	content::RenderFrameHostImpl::OnMessageReceived(IPC::Message const&)
0x0000000107b01c7a	(Google Chrome Framework -ipc_channel_proxy.cc:339 )	IPC::ChannelProxy::Context::OnDispatchMessage(IPC::Message const&)
0x000000010718f298	(Google Chrome Framework -callback.h:64 )	base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask const&)

Sounds like POST submissions to the CWS aren't leading to a process swap?  That could be related to OpenURL changes.  (clamy@ also just landed something that changes how transfers work, but that's only in M55, not M53.)

I would normally expect the CWS to force a transfer, even for POST submissions.

I repro'd on M53 (crash 107e281d00000000), but neither alexmos@ nor I can repro on M55.  Strange, since the crash ID in comment 2 (7307403e00000000) does indicate it's from 55.0.2880.0.

I tried to repro this using the file in #3, and I see no kills for both Mac canary (55.0.2880.0) and Linux dev (55.0.2873.0).  I did confirm the kill on stable.  That said, #2 indicates it does happen on canary, so I'm curious how that's different from what I tried.

Also,  issue 622385  was different: that had to do with CWS kill in subframes, whereas this is for main frames.  So that issue didn't come back, and this issue is new.

I reproduced this with 55.0.2880.0 canary Mac with the following URL:

data:text/html;charset=utf-8,<form method="POST" action="https://chrome.google.com/webstore/"> <input type="submit" value="Ok"> </form>

Server ID: fd9f6c3e00000000

Ah, got it.  My canary had --site-per-process enabled, and there's no kill in that mode.  After I turned it off, I reproed the crash on canary using tkent's URL.

Lukasz agreed to triage this further (thanks Lukasz!)

I am not sure what is going on in M53, but in M55 this seems to be a relatively recent regression - I got no repro on 55.0.2873.0 (dev channel), but I did get a repro on 55.0.2880.0 (canary).  After bisecting using the tool, I see that the recent regression is caused by my earlier CL [r421645] that started to again avoid OpenURL path for POST requests (I've confirmed this via local builds right before and right after this CL).

Tested the issue on chrome Stable #53.0.2785.143, Canary 55.0.2880.4 in Windows 10.0 and was able to reproduce the issue using steps provided in comment#8 

URL:(data:text/html;charset=utf-8,<form method="POST" action="https://chrome.google.com/webstore/"> <input type="submit" value="Ok"> </form>).

This is a Non-Regression issue since seeing this from M30 #30.0.1549.0(208818), Making the status to Untriaged so that the issue would get addressed.

Note : Able to reproduce the issue in MAC 10.12 and Linux Ubuntu 14.04.

Thank you.

It is not entirely clear to me whether this bug only impacts Chrome Web Store (where renderer will be killed, so little or no security risk/impact) or whether an exploited renderer can also commit *other* apps within a renderer hosting web content.  Because of that let me mark this as a security bug + add view restrictions.  Just in case.

So far I see that 
    #2 0x7fe6ce789832 extensions::CrossesExtensionProcessBoundary()
    #3 0x7fe6cf4d4188 extensions::ChromeContentBrowserClientExtensionsPart::ShouldSwapProcessesForRedirect()
    #4 0x7fe6c38a57a5 content::NavigationHandleImpl::MaybeTransferAndProceedInternal()
    #5 0x7fe6c38a09ae content::NavigationHandleImpl::MaybeTransferAndProceed()
    #6 0x7fe6c38a2fae content::NavigationHandleImpl::WillProcessResponse()
returns false, because both the |old_url| and the |new_url| belong to Chrome Web Store (in fact, these urls are identical).  I need to dig a bit more to figure out why these urls are the same.

One thing that strikes me as a bit odd is that ShouldSwapProcessesForRedirect and CanCommitURL have to make their decision based on different data:
- CanCommitURL looks whether process_host contains the new_extension
- ShouldSwapProcessesForRedirect looks whether old and new url belong to different extension (where "web" counts as a special NULL extension).  OTOH, I guess that |process_host| is not yet known at this point?

Since r421645 was merged back to M54 (to 54.0.2840.45), this probably also impacts M54 (currently Beta and soon-to-become Stable).

Hmmm... |old_url| and |new_url| in extensions::CrossesExtensionProcessBoundary are taken from NavigationHandle's |original_url_| and |url_| [1].  This doesn't seem right (or rather - using ShouldSwapProcessesForRedirect for non-redirect cases seems wrong).  FWIW, the arguments to ShouldSwapProcessesForRedirect don't seem to significantly change before/after recent navigation refactoring in clamy@'s r421216 (before this CL ShouldSwapProcessesForRedirect would be called from CrossSiteResourceHandler::OnNormalResponseStarted with request()->original_url(), request()->url() [2]).

[1] https://chromium.googlesource.com/chromium/src/+/f40a0349f8575ccd544d6844dccd56119b87170c/content/browser/frame_host/navigation_handle_impl.cc#661

[2] https://chromium.googlesource.com/chromium/src/+/9d13729984128b2970874d8f729ff5f77cd1158e/content/browser/loader/cross_site_resource_handler.cc#167 

One more interesting finding - I see that ChromeContentBrowserClientExtensionsPart::DoesSiteRequireDedicatedProcess returns false for chrome-extension://ahfgeienlihckogmohjhadlkjgocpleb (the CWS), because it is a hosted app.  Maybe we need an exception for CWS here?

+lazyboy@ and nick@ - the fix requires further tweaks to the logic added in r399229 and r354038 to ChromeContentBrowserClientExtensionsPart::DoesSiteRequireDedicatedProcess in chrome/browser/extensions/chrome_content_browser_client_extensions_part.cc.

Status update - I have a fix + test proposal and I am running tryjobs at https://codereview.chromium.org/2400523002

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

commit 2a130dcac2715c1ebf7e2666355e007bd71f3b44
Author: lukasza <lukasza@chromium.org>
Date: Thu Oct 06 00:50:43 2016

Isolating Chrome Web Store app in the transfer (i.e. non-OpenURL) path.

BUG=652708

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

[modify] https://crrev.com/2a130dcac2715c1ebf7e2666355e007bd71f3b44/chrome/browser/extensions/chrome_content_browser_client_extensions_part.cc
[modify] https://crrev.com/2a130dcac2715c1ebf7e2666355e007bd71f3b44/chrome/browser/extensions/process_management_browsertest.cc

Marking severity low out of an abundance of caution; this appears to be a bad message kill due to faulty logic and not a security issue per-se.

I've verified that repro steps from #c8 don't work anymore on 55.0.2883.0 (Official Build) canary (64-bit) on Windows 7.

I also don't see any crashes after version 55.0.2880.4 (prior to that, there were 1-4 crashes per canary).

This crash^H^H^H renderer kill seems rather low volume - at this point I don't think we need to merge the fix back to M54:

- This is ranked #115 in version 55.0.2880.0 (at 4 crashes ~ 0.1% of crashes).

- Earlier spikes where in 52.0.2743.116, 53.0.2785.116 and 53.0.2785.143, but still well below 0.01% (yes - there is an extra 0 there).

So I have the right to reward?

Thanks for following up.  It isn't my decision, but I can add reward-topanel which should put this in the queue. 

Thanks!

Greetings.  I'm sorry to say this is a low severity bug that results in a DoS at worst, so isn't eligible for a reward.  But thank you for the report - keep them coming :-)

No problem ;)
regards.

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

commit 2a130dcac2715c1ebf7e2666355e007bd71f3b44
Author: lukasza <lukasza@chromium.org>
Date: Thu Oct 06 00:50:43 2016

Isolating Chrome Web Store app in the transfer (i.e. non-OpenURL) path.

BUG=652708

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

[modify] https://crrev.com/2a130dcac2715c1ebf7e2666355e007bd71f3b44/chrome/browser/extensions/chrome_content_browser_client_extensions_part.cc
[modify] https://crrev.com/2a130dcac2715c1ebf7e2666355e007bd71f3b44/chrome/browser/extensions/process_management_browsertest.cc

I think we may need an updated fix for this, now that Nasko has landed r428775 (making --isolate-extensions off by default until we're ready to launch).  Apparently that regressed the fix and the kills are possible again?

It seems that POST to CWS never worked before r423360 (the fix from #c19) - I see a renderer kill using repro from #c8 when --isolate-extensions mode is disabled on:
- 49.0.2623.112
- 52.0.2743.119
- 53.0.2785.157
- 54.0.2840.71
- ToT

With --isolate-extensions (and the fix from #c19) we get proper isolation of CWS (and no kill) when --isolate-extensions mode is enabled.

Given this, I am not sure if there is anything to be done here.

PS. The merge-merged-2840 label seems to have been applied by mistake - the fix from #c19 wasn't merged anywhere AFAICT (i.e. using "find-releases" tool).

In an offline chat creis@ pointed out that even though there is no regression here (*), having a renderer kill for a web navigation is wrong.  Therefore we shouldn't close this bug just yet.

OTOH, I think it is fine to mark this bug as low priority, because
1) one way to "fix" this bug is to just wait until --isolate-extensions ships (hopefully in M56).
2) as pointed out above, the kill happens during an scenario that was never supported by CWS (prior to M54 and M55 and --isolate-extensions related changes).

(*) as pointed out in #c34 the POST to CWS was never supported without --isolate-extensions, except for a brief period in M54 and M55 when POST was handled via OpenURL.

[Automated comment] removing mislabelled merge-merged-2840

Hello,

I installed the latest version of Google Chrome for windows (Version 55.0.2883.75 m) and the bug has already been fixed. The page shows a 404 error

But in the official blog, no mention is made of the researcher :(

https://googlechromereleases.blogspot.com.es/

awhalley@, could you please help answer #c37 above?

In Version 55.0.2883.87 m the crash occurs again

The crash should not happen with --isolate-extensions (which is turned off in M55; we hope to ramp it up to 100% once M56 reaches stable).  The crash is understood and believed to be low-priority to fix (as I tried to explain in #c35 - please shout if anything here or there seems wrong).

forgive me for insisting,
the following url causes a crash in google chrome Versión 57.0.2987.98 and Versión 59.0.3042.4 (Build oficial) canary (64 bits)

data:text/html,<form action="https://chrome.google.com/webstore?rt" method="post"><input type="submit"></form>

Mozilla returns error "400 Bad Request"

Request headers:

Content-Disposition: attachment; filename="response.txt"
Content-Encoding: gzip
Content-Type: application/json; charset=UTF-8

To consider in Google Chrome:

1) This url does not crash (error 400):

data:text/html,<form action="https://chrome.google.com/webstore" method="post"><input type="submit"></form>

2) This url (add the parameter rt) cause a crash:

data:text/html,<form action="https://chrome.google.com/webstore?rt" method="post"><input type="submit"></form>

Crashed ID 602423a9-3261-4a12-90f3-2d447a813150 (ID server: 81a3fc9d80000000)

Since it is a low security bug, could they make it public?

re #43 - since we're not tracking this as a security bug, yes, it can be made public.

Comments 41-42: Thanks for pointing out the renderer kill still happens on some error pages.  --isolate-extensions has launched, and apparently that helps with the /webstore case but not the /webstore?rt case.

We have some ongoing plans to change the way error pages work that would help avoid this issue, and it may be worth looking closer to see why this /webstore?rt case behaves differently.  However, I do agree this is somewhat low priority given that the navigation wouldn't be supported anyway.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot