Triaging to Blink>Loader, especially with the repro step to enable experimental WP features.

I could not repro on 51.0.2704.79 (64-bit) Linux.

I can repro on 53.0.2760.0 OSX. netlog shows a successful URL_REQUEST to the page but for some reason it is not committing.

Ok I was also able to repro with 51 - I hadn't restarted Chrome properly to enable the experimental web platform features. Let's bisect this.

Looks like the crashes are coming from renderer termination - RFH_INVALID_ORIGIN_ON_COMMIT (https://cs.chromium.org/chromium/src/content/browser/frame_host/render_frame_host_impl.cc?rcl=1465197654&l=1059)

The same behavior is observed in Chrome 51.0.2704.36 for Android 6.0.99; Build/NPD35K if experimental web platform features are enabled.

Bisected down to a single commit: https://codereview.chromium.org/1775543002

nasko@, can you take a look at why this message is triggering? 

This looks very much like the issue I've recently discovered with suborigins, which is an experimental web feature. It is indeed proven by forcing SecurityOrigin::deserializeSuboriginAndHost to always return false, which fixes the issue and allows the site to be loaded.

The reason for the kill is that the origin doesn't match the URL, because suborigins use underscore as a delimiter for serializing the suborigin.

RFH[0x618000158c80]::OnDidCommitProvisionalLoad:  params.origin:https://animals.dirty.ru params.url:https://extinct_animals.dirty.ru/

Assigning to jww@ to follow up, as he is working on suborigins.

Indeed, this is a known issue with Suborigins. nasko@ filed https://github.com/w3c/webappsec-suborigins/issues/38 to track it in the spec. We should probably, in the short term, come up with an alternative serialization in Chrome to un-break this on Experimental Web Platform Features. I'll try to think of what we should do here.

These renderer kills are still happening in the wild.  Joel, is there something we can do to prevent them?

We're investigating various renderer kills in issue 613260.  One example of this type of kill is ba9b15e600000000, which has bad_message_reason 114 (RFH_INVALID_ORIGIN_ON_COMMIT).  Note that the highlighted line in the stack trace is wrong, as explained in comment 38 of issue 473370.

Oh, right-- Joel is OOO!  estark@ or mkwst@, do you know who else might know about suborigins and how we can avoid these renderer kills?

Hrm. It looks like the GitHub discussion has stalled, with a number of issues listed, but with no clear progress in the last ~2 weeks.

Short-term, we can move suborigins from "experimental" to "test" on ToT and the stable channel while we ponder a better solution. That will make internal testing a little bit more complicated, but that's probably the right tradeoff, since I don't think Emily or I have enough context paged in to make intelligent decisions about the feature (and Joel's not going to be gone _that_ long :) ).

Uploaded https://codereview.chromium.org/2094873004 to do just that.

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

commit 66ab9f9074c3d1082a7ab1062914fece3810c104
Author: mkwst <mkwst@chromium.org>
Date: Fri Jun 24 09:21:37 2016

Move the suborigin experiment to test-only mode.

We're seeing crashes in the wild for folks with the experimental features
flag turned on, as our suborigins implementation breaks origins that
natively use an underscore in their DNS name (renderer crash with
bad_message_reason 114 (RFH_INVALID_ORIGIN_ON_COMMIT)).

This patch moves suborigins behind the test flag, so that it isn't
enabled for users who have opted into experimental web platform
features. We expect to re-enable it for those users once we've reworked
serialization in https://github.com/w3c/webappsec-suborigins/issues/38

BUG= 617588 
TBR=jww@chromium.org

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

[modify] https://crrev.com/66ab9f9074c3d1082a7ab1062914fece3810c104/third_party/WebKit/Source/platform/RuntimeEnabledFeatures.in

Let's let the patch bake through a Canary, and if it looks sane, merge it back to whatever the friendly release managers will let me merge it back to.

[Automated comment] Request affecting a post-stable build (M51), manual review required.

Your change meets the bar and is auto-approved for M52 (branch: 2743)

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

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

Your change meets the bar and is auto-approved for M52 (branch: 2743)

Rechecked this on chrome version 53.0.2780.0 on Windows, MAC OS, Ubuntu 14.04, followed the below steps:

1) Enabled the Flag:#enable-experimental-web-platform-features
2) Navigated to https://extinct_animals.dirty.ru/
3) Did not observe any crashes on the page.

Adding TE-verified labels.

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

commit 307cf74bd38a7bb5482414061ada0da713f72a2f
Author: Mike West <mkwst@google.com>
Date: Mon Jun 27 11:23:23 2016

Move the suborigin experiment to test-only mode.

We're seeing crashes in the wild for folks with the experimental features
flag turned on, as our suborigins implementation breaks origins that
natively use an underscore in their DNS name (renderer crash with
bad_message_reason 114 (RFH_INVALID_ORIGIN_ON_COMMIT)).

This patch moves suborigins behind the test flag, so that it isn't
enabled for users who have opted into experimental web platform
features. We expect to re-enable it for those users once we've reworked
serialization in https://github.com/w3c/webappsec-suborigins/issues/38

BUG= 617588 
TBR=jww@chromium.org

Review-Url: https://codereview.chromium.org/2094873004
Cr-Commit-Position: refs/heads/master@{#401840}
(cherry picked from commit 66ab9f9074c3d1082a7ab1062914fece3810c104)

Review URL: https://codereview.chromium.org/2094263002 .

Cr-Commit-Position: refs/branch-heads/2743@{#481}
Cr-Branched-From: 2b3ae3b8090361f8af5a611712fc1a5ab2de53cb-refs/heads/master@{#394939}

[modify] https://crrev.com/307cf74bd38a7bb5482414061ada0da713f72a2f/third_party/WebKit/Source/platform/RuntimeEnabledFeatures.in

Thanks Mike!  The quick fix is much appreciated.

Hmm, either I spoke too soon or there's another way to get to this kill.  I'm still seeing crashes after 53.0.2779.0, when r401840 made it to Canary.

For example, c301109600000000 is in 53.0.2780.0 and has bad_message_reason 114 in the crash keys, corresponding to RFH_INVALID_ORIGIN_ON_COMMIT.

Mike, this would be unexpected after your CL, right?  Nasko, can you take a look at the minidump to see if any URL can be recovered?

Crash query:
https://crash.corp.google.com/browse?q=product.name%3D%27Chrome%27%20AND%20product.version%3E%3D%2753.0.2779.0%27%20AND%20custom_data.ChromeCrashProto.ptype%3D%27browser%27%20AND%20custom_data.ChromeCrashProto.magic_signature_1.name%3D%27%5BRenderer%20kill%5D%20content%3A%3ARenderFrameHostImpl%3A%3AOnDidCommitProvisionalLoad%27&ignore_case=false&enable_rewrite=true&omit_field_name=&omit_field_value=&omit_field_opt=%3D

> Mike, this would be unexpected after your CL, right?

Yes, that would be unexpected, though I'm sure it's possible that we missed checking the feature flag somewhere.

If y'all can provide URLs, that'd be wonderful; I also confirmed that the https://extinct_animals.dirty.ru/ site didn't crash, with or without the experimental features flag.

Verified this on chrome latest M52-52.0.2743.60 on Windows, MAC OS, Ubuntu 14.04 by following steps provided in the original comment. Observed no crashes while loading the page https://extinct_animals.dirty.ru/. The fix is working as intended, Hence adding TE-verified label.

Thanks!

Are we still seeing crashes after this "fix"? Is there anything here that we still want to consider for M51? Please note the bar is very high for merges into post-stable M51 at this point. 

I'll resolve this one as fixed, since the root cause of underscore in the hostname is fixed. However, there are more of those process kills, so I've filed  issue 628677  to track the remaining reasons.