Automatically applying components based on crash stacktrace and information from OWNERS files.

If this is incorrect, please apply the Test-Predator-Wrong-Components label.

clamy@: This looks like a possible regression from r599176, which landed in 72.0.3579.0.  Can you take a look?

Looks like there's a report in the wild as well: crash/d4ab8c03c2aa5dae

So I managed to repro the test case. This happens on an OpenURL call to navigate to about:srcdoc. Our computation of url_to_load yields chrome://srcdoc while what we have in the FrameEntry is about:srcdoc.

So the issue is that in NavigateFromFrameProxy, we create a temporary FrameNavigationEntry, and we pass it the URL we received and not its rewritten version. I think this is a bug and have a fix for it at https://chromium-review.googlesource.com/c/chromium/src/+/1282992.

Not that the crash report is for a different stack. I'm going to investigate.

Quick note (which I mentioned on the CL): I think we want the outcome to be about:srcdoc for the subframe rather than chrome://srcdoc.  We generally shouldn't be doing virtual URL style rewriting for subframes.

Looks like the external reports (which do seem to have a variety of stacks) are tracked in issue 896028.

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

commit 2baa802799f9aebcc169d436d39ce10920b440d4
Author: Camille Lamy <clamy@chromium.org>
Date: Fri Oct 19 16:43:17 2018

Don't rewrite subframe navigation URLs

This CL makes sure we do not attempt to rewrite a subframe navigation URL in
should only be performed on main frame navigations.

NavigationControllerImpl: :CreateNavigationRequestFromLoadParams. Rewrites
Bug:  895065 , 803859, 896028
Change-Id: I2a2326d802b55655d59f0c6d3d73e3060c58152b
Reviewed-on: https://chromium-review.googlesource.com/c/1282992
Commit-Queue: Charlie Reis <creis@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#601183}
[modify] https://crrev.com/2baa802799f9aebcc169d436d39ce10920b440d4/content/browser/browser_url_handler_impl.cc
[modify] https://crrev.com/2baa802799f9aebcc169d436d39ce10920b440d4/content/browser/browser_url_handler_impl.h
[modify] https://crrev.com/2baa802799f9aebcc169d436d39ce10920b440d4/content/browser/frame_host/navigation_controller_impl.cc
[modify] https://crrev.com/2baa802799f9aebcc169d436d39ce10920b440d4/content/browser/frame_host/navigation_controller_impl_unittest.cc

ClusterFuzz has detected this issue as fixed in range 601181:601185.

Detailed report: https://clusterfuzz.com/testcase?key=5383666585567232

Fuzzer: ochang_domfuzzer
Job Type: linux_asan_chrome_mp
Platform Id: linux

Crash Type: CHECK failure
Crash Address: 
Crash State:
  url_to_load == frame_entry->url() in navigation_controller_impl.cc
  content::NavigationControllerImpl::CreateNavigationRequestFromLoadParams
  content::NavigationControllerImpl::NavigateFromFrameProxy
  
Sanitizer: address (ASAN)

Fixed: https://clusterfuzz.com/revisions?job=linux_asan_chrome_mp&range=601181:601185

Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5383666585567232

See https://github.com/google/clusterfuzz-tools for more information.

If you suspect that the result above is incorrect, try re-doing that job on the test case report page.

ClusterFuzz testcase 5383666585567232 is verified as fixed, so closing issue as verified.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.