Update:
Bisect info:
You are probably looking for a change made after 596362 (known good), but no later than 596397 (first known bad).

CHANGE-LOG URL:
https://chromium.googlesource.com/chromium/src/+log/0e4fa12cb9ff909f981579e3d018a45d0f2f8153..48142096a60f26a702039a263731a35e4456fdf3

Suspect:r 596386 and r 596376

@Clark DuVall:Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Thank You!

Update:
Kindly refer to the attached log file from chrome://net-export.
thank you...

Deleted: Chrome::settings.json 3.4 MB

Chrome::settings.json 3.4 MB View Download

Adding release blocker label for this issue.Please reduce priority or remove if not the case.

Thank You!

I finished the bisect, and it looks like the culprit is http://crrev.com/2f8101670e3ac82b0d80bdd58b9d16334699360c. The DCHECK is being hit here: https://cs.chromium.org/chromium/src/content/browser/frame_host/render_frame_host_impl.cc?l=4953&rcl=1e301632a27b3bcf29de1a7fb48dcb40ec7d47d0

Thank you very much for catching the bug and for routing it to me!

I suspect that the problem is that RenderFrameHostImpl::UpdateSubresourceLoaderFactories does not go through the same steps as RenderFrameHostImpl::CommitNavigation for creating the factories.  In particular service workers, WebUI and non_network_url_loader_factories_ are ignored.

The problem above started surfacing after r596378, because it started calling RenderFrameHostImpl::UpdateSubresourceLoaderFactories in more situations (i.e. before this change, UpdateSubresourceLoaderFactories would never be called for WebUI pages).  Still, the problem above was indeed a problem even before r596378 - for example:
- a http/https: page would loose access to filesystem: factory after a NetworkService crash
- a chrome-extension: page would looses access to file: factory (granted to extensions loaded as "unpacked") after a NetworkService crash

I am still trying to validate the hypothesis above + figure out how filesystem: URLs work (so that I can add a test that covers them under NetworkServiceRestartBrowserTest).

Is it possible to have a small cl to disable the separate URLLoaderFactory for extensions while this is being fixed? We're in the middle of trying to understand why we have less UMA stats from folks in the network service experiment (bug 892363), and one theory is that we might have a bug that causes them to stop using it (it's before this regression, so it's not this bug). We were planning on reshuffling the canary population, but we don't want to do that if there are any bugs that could be serious and therefore affect the new shuffled groups.

Status update:

- Small CL (mergeable to M71) that disables separate URLLoaderFactories for extensions: https://crrev.com/c/1279170 (in CQ)

- Real fix (because of the above no need to merge to M71): https://crrev.com/c/1279177
    - Still need to add tests
    - Need to also avoid cloberring the default factory after a network process crash
      (while still 1) trigerring a refresh and 2) refreshing initiator/extension-specific
       factories that may be needed in content scripts injected into [say] WebUI page)


Also - In #c7 I incorrectly assumed that RenderFrameHostImpl::UpdateSubresourceLoaderFactories always clears scheme-specific factories in the renderer (since it sense URLLoaderFactoryBundleInfo with an empty scheme_specific_factory_infos).  In fact, mojom::Frame::UpdateSubresourceLoaderFactories preserves old renderer-side factories, unless the input explicitly contains their replacements.  This means that I was not correct when saying that there was a problem before r596378.

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

commit b4013627cedb0d1ceab9db55ea93e401ad764a18
Author: Lukasz Anforowicz <lukasza@chromium.org>
Date: Sat Oct 13 00:14:50 2018

Temporarily disable separate URLLoaderFactories for extensions.

Disabling separate URLLoaderFactories for extensions should help ensure
that things are stable in M71, while we work on a real fix for
 https://crbug.com/894766  in M72.

This CL can be seen as a manual, minimal revert of r596378.

Bug:  894766 
Cq-Include-Trybots: luci.chromium.try:linux_mojo
Change-Id: I1cad01be3789b335be00399432d82ef74266a5ab
Reviewed-on: https://chromium-review.googlesource.com/c/1279170
Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Cr-Commit-Position: refs/heads/master@{#599434}
[modify] https://crrev.com/b4013627cedb0d1ceab9db55ea93e401ad764a18/chrome/browser/extensions/chrome_content_browser_client_extensions_part.cc
[modify] https://crrev.com/b4013627cedb0d1ceab9db55ea93e401ad764a18/content/public/browser/site_isolation_policy.cc
[modify] https://crrev.com/b4013627cedb0d1ceab9db55ea93e401ad764a18/extensions/browser/url_loader_factory_manager.cc
[modify] https://crrev.com/b4013627cedb0d1ceab9db55ea93e401ad764a18/extensions/shell/browser/shell_content_browser_client.cc
[modify] https://crrev.com/b4013627cedb0d1ceab9db55ea93e401ad764a18/services/network/public/mojom/network_context.mojom
[modify] https://crrev.com/b4013627cedb0d1ceab9db55ea93e401ad764a18/services/network/url_loader.cc

Update:

Rechecked the above issue using latest canary build#72.0.3581.0 on Mac(10.12.6, 10.13.1, 10.14, 10.13.6) Windows (7, 8, 8.1 ,10) and Linux 14.04 LTS and issue is fixed.

Please find below attached screen cast

Thank You...

Deleted: Canary_Behaviour#72.0.3581.0.mov 12.7 MB

	Canary_Behaviour#72.0.3581.0.mov 12.7 MB View Download

let's merge this back to M71 since it was cut. https://crrev.com/c/1279170

Right - I support the request for merging r599434 into M71:

- The fix reverts foundations for *future* security features
  (so the "revert" aspect doesn't matter for M70)

- The revert CL is relatively small and should result in behavior
  that has been stable and more-or-less unchanged for a while (no
  major changes since ~M67 for the non-NetworkService path and no
  major changes since ~M69 for the NetworkService path)

s/doesn't matter for M70/doesn't matter for M71/ ...

govind@ - could you PTAL at the M71 merge request in #c13-#c15?

Approving merge to M71 branch 3578 based on comments #14. Pls merge now.

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

commit ed37d83e963ab34f3498bfabd96a4757e5375548
Author: Lukasz Anforowicz <lukasza@chromium.org>
Date: Tue Oct 16 20:51:00 2018

Temporarily disable separate URLLoaderFactories for extensions.

Disabling separate URLLoaderFactories for extensions should help ensure
that things are stable in M71, while we work on a real fix for
 https://crbug.com/894766  in M72.

This CL can be seen as a manual, minimal revert of r596378.

TBR=lukasza@chromium.org

(cherry picked from commit b4013627cedb0d1ceab9db55ea93e401ad764a18)

Bug:  894766 
Cq-Include-Trybots: luci.chromium.try:linux_mojo
Change-Id: I1cad01be3789b335be00399432d82ef74266a5ab
Reviewed-on: https://chromium-review.googlesource.com/c/1279170
Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#599434}
Reviewed-on: https://chromium-review.googlesource.com/c/1284534
Reviewed-by: Łukasz Anforowicz <lukasza@chromium.org>
Cr-Commit-Position: refs/branch-heads/3578@{#63}
Cr-Branched-From: 4226ddf99103e493d7afb23a4c7902ee496108b6-refs/heads/master@{#599034}
[modify] https://crrev.com/ed37d83e963ab34f3498bfabd96a4757e5375548/chrome/browser/extensions/chrome_content_browser_client_extensions_part.cc
[modify] https://crrev.com/ed37d83e963ab34f3498bfabd96a4757e5375548/content/public/browser/site_isolation_policy.cc
[modify] https://crrev.com/ed37d83e963ab34f3498bfabd96a4757e5375548/extensions/browser/url_loader_factory_manager.cc
[modify] https://crrev.com/ed37d83e963ab34f3498bfabd96a4757e5375548/extensions/shell/browser/shell_content_browser_client.cc
[modify] https://crrev.com/ed37d83e963ab34f3498bfabd96a4757e5375548/services/network/public/mojom/network_context.mojom
[modify] https://crrev.com/ed37d83e963ab34f3498bfabd96a4757e5375548/services/network/url_loader.cc

Update:

Rechecked the above issue using latest Dev build# 71.0.3578.10 on Mac(10.12.6, 10.13.1, 10.14, 10.13.6) Windows (7, 8, 8.1 ,10) and Linux 14.04 LTS and issue is fixed.

Please find below attached screen cast

Thank You...

Deleted: Dev_behaviour.mov 12.3 MB

	Dev_behaviour.mov 12.3 MB View Download

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

Commit: ed37d83e963ab34f3498bfabd96a4757e5375548
Author: lukasza@chromium.org
Commiter: lukasza@chromium.org
Date: 2018-10-16 20:51:00 +0000 UTC

Temporarily disable separate URLLoaderFactories for extensions.

Disabling separate URLLoaderFactories for extensions should help ensure
that things are stable in M71, while we work on a real fix for
 https://crbug.com/894766  in M72.

This CL can be seen as a manual, minimal revert of r596378.

TBR=lukasza@chromium.org

(cherry picked from commit b4013627cedb0d1ceab9db55ea93e401ad764a18)

Bug:  894766 
Cq-Include-Trybots: luci.chromium.try:linux_mojo
Change-Id: I1cad01be3789b335be00399432d82ef74266a5ab
Reviewed-on: https://chromium-review.googlesource.com/c/1279170
Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#599434}
Reviewed-on: https://chromium-review.googlesource.com/c/1284534
Reviewed-by: Łukasz Anforowicz <lukasza@chromium.org>
Cr-Commit-Position: refs/branch-heads/3578@{#63}
Cr-Branched-From: 4226ddf99103e493d7afb23a4c7902ee496108b6-refs/heads/master@{#599034}