There's a few options for fixing:
1) Move base URL and history URL to FrameNavigationEntry, so we don't mix the values between main frames and subframes.
This could make sense, but it might be unnecessary overhead to have for all frames if subframes can't use loadDataWithBaseURL.

2) Don't pass base URL and history URL values for subframes from the browser process (while keeping them on NavEntry).
This seems safe and somewhat more efficient, assuming they're never needed for subframes.

3) Don't use base URL and history URL values for subframes in the renderer process, even if they're passed down.
This is redundant, but it's arguably the safest change to land and merge to other branches.  We could add fix #2 later along with some additional cleanup.

Note that many of the values in ConstructCommonNavigationParams seem like they may have a similar bug, where they use the value from the main frame for subframe navigations.  I'll confirm and fix if so.

boliu@: Can you confirm whether loadDataWithBaseURL is only allowed on the main frame?  I think so, since I don't see how it would work for a subframe.

Also, it looks like this might not be specific to same-document navigations.  (I get a similar test failure for cross-document subframe navigations.)

boliu@: You mentioned you were seeing it fail on a DCHECK and an origin CHECK?  I'm seeing a different failure (i.e., the else branch of the DataURL::Parse condition):

    CHECK(false) << "Invalid URL passed: "
                 << params.url.possibly_invalid_spec();

I'll look closer tomorrow, but it might help if you let me know which line you were seeing fail in practice if it was different.  Thanks!

Initial CL here: https://chromium-review.googlesource.com/c/chromium/src/+/683341

Yes, loadDataWithBaseURL only applies to the main frame.

I was using a few releases back, and it was failing on this check:
https://cs.chromium.org/chromium/src/content/renderer/render_frame_impl.cc?rcl=37ad670b857bd0c1cef752bba9d2c43d995d5bfc&l=5119

url was the base url of the top level loadDataWithBaseURL frame, and origin was the url of the subframe

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

commit c44784177e34421934fe40e7218bb350bb466d66
Author: Charles Reis <creis@chromium.org>
Date: Tue Sep 26 07:20:57 2017

Don't use base URL and history URL for subframe navigations.

BUG= 768575 
TEST=See bug for repro steps

Cq-Include-Trybots: master.tryserver.chromium.linux:linux_site_isolation
Change-Id: I0c64d13dcea6a13b622ec250d55327972fe77390
Reviewed-on: https://chromium-review.googlesource.com/683341
Commit-Queue: Charlie Reis (catching up) <creis@chromium.org>
Reviewed-by: Bo <boliu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#504302}
[modify] https://crrev.com/c44784177e34421934fe40e7218bb350bb466d66/content/browser/frame_host/navigation_controller_impl_browsertest.cc
[modify] https://crrev.com/c44784177e34421934fe40e7218bb350bb466d66/content/renderer/render_frame_impl.cc

The fix landed in r504302 (should be in tomorrow's canary), and I filed  issue 769048  for the followup work.

boliu@: How are merges handled for Android Webview issues?  I don't think this bug affects other platforms, but I imagine we'd want to merge it anyway.  Is there a way we can verify the fix before requesting merge?

Webview is built from directly chromium source, so merge is done exactly same way as chrome, crbug merge labels, git drover or whatever your favourite merge steps you want to use

I verified local trunk no longer crashes.

Great, that simplifies things.  I'll let it bake on Canary for a day and then request merge to M62.

This has baked on Canary since 63.0.3225.0 and the Android Webview fix was verified in comment 7, so I'm requesting to merge to M62.

For context on severity and why it's important to merge, please see b/34220171.

This will fix the following crash:

https://crash.corp.google.com/browse?q=product.name%3D%27AndroidWebView%27%20AND%20custom_data.ChromeCrashProto.magic_signature_1.name%3D%27content%3A%3ARenderFrameImpl%3A%3ALoadDataURL%27&sql_dialect=dremelsql&ignore_case=false&enable_rewrite=true&omit_field_name=&omit_field_value=&omit_field_opt=%3D#-property-selector,productversion:1000

This bug requires manual review: M62 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), bhthompson@(ChromeOS), abdulsyed@(Desktop)

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

What is the risk associated with merging this bug into M62 at this time? Since this is not a regression in M62, Do we need more time for this fix to bake in M63 Dev and Beta before pushing it?

This is a very targeted fix which should be a safe merge, since subframes are never meant to use loadDataWithBaseURL functionality.  The reason for the merge is that it's causing a lot of crashes in a popular use case, and has been for too long (see b/34220171).  That bug took a long time to triage and find the cause, but I think it is important to get the fix out as soon as possible.

Sounds good! Merge approved!
Please make sure to verify the fix after merging it into M62 branch.

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

commit d09b1946852e160bd8c7d9c689bef9ab251cd80c
Author: Charles Reis <creis@chromium.org>
Date: Fri Sep 29 00:38:52 2017

Don't use base URL and history URL for subframe navigations.

BUG= 768575 
TEST=See bug for repro steps
TBR=creis@chromium.org

(cherry picked from commit c44784177e34421934fe40e7218bb350bb466d66)

Cq-Include-Trybots: master.tryserver.chromium.linux:linux_site_isolation
Change-Id: I0c64d13dcea6a13b622ec250d55327972fe77390
Reviewed-on: https://chromium-review.googlesource.com/683341
Commit-Queue: Charlie Reis (catching up) <creis@chromium.org>
Reviewed-by: Bo <boliu@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#504302}
Reviewed-on: https://chromium-review.googlesource.com/691184
Reviewed-by: Charlie Reis <creis@chromium.org>
Cr-Commit-Position: refs/branch-heads/3202@{#498}
Cr-Branched-From: fa6a5d87adff761bc16afc5498c3f5944c1daa68-refs/heads/master@{#499098}
[modify] https://crrev.com/d09b1946852e160bd8c7d9c689bef9ab251cd80c/content/browser/frame_host/navigation_controller_impl_browsertest.cc
[modify] https://crrev.com/d09b1946852e160bd8c7d9c689bef9ab251cd80c/content/renderer/render_frame_impl.cc

Issue verified on Monochrome/Webview: 62.0.3202.45, tested on Nexus5X/OPR1.170623.011 and Asus Zenfone 2Laser(ZE551KL)/MMB29P, with steps and apk(NewsWeather_3.4.0.apk) provided in #47 of b/34220171.