Can you provide a NetLog dump, following the instructions at https://www.chromium.org/for-testers/providing-network-details?

Okay. One log (log4) is attached here. The browser seems to consistently break when interacting with http://jobscan.co, whether gmail is open or not.
However, I captured some other logs (described below), two of which are over the 10mb limit to upload here.I have uploaded to Google Drive, but can submit another way if you need something more secure. 
https://drive.google.com/open?id=1oCFVpk0--TOgIZDicyAPdzjyGLJkG9D4

So, for log and log1, going to https://jobscan.co and trying to log in through their Linkedin API connection seemed to break the browser. A number of other times that I didn't log, it would crash every time at jobscan.co. For log2, it was just normal browsing that did not include going to jobscan.co that crashed the browser. log3 suddenly had the jobscan.co link working fine (after I would guess about a dozen crashes; I didn't log every time), so this is an example of no error, but might show a difference to compare to log and log2?

Deleted: chrome-net-export-log4.json 5.4 MB

chrome-net-export-log4.json 5.4 MB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

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

If Chrome was crashing when you were trying to reproduce this, can you also provide the crash id (instructions at https://www.chromium.org/for-testers/bug-reporting-guidelines/reporting-crash-bug)? The only sign of connections or requests failing that I see in the net logs is the websocket for socket.wunderlist.com:8443 failing as connection refused.

If you disable extensions, does this issue still happen?

When you say that tabs stop responding to attempts to navigate or make requests, are you seeing a net error page saying something like "This site can't be reached" and a line that starts ERR_, or are you seeing some other behavior?

Sorry, I misphrased with "crashed." All tabs just hang and pretend that they're loading with statuses like "Establishing secure connection..." or "Waiting for [url]..." There have not been net error pages, tabs just hang in place.
I tried disabling several extensions, and have found that issue is probably related to Adblock. However, it behaves a little strangely.
I found that when I open Chrome with Adblock installed, I continue to have this issue at jobscan.co; it will load the initial page but then hangs if I try to do anything on the site. The Adblock plugin will also become unresponsive at this point. When I remove Adblock from Chrome, it immediately starts working again. However, it also will continue to work if I reinstall Adblock in the same session. The plugin itself becomes responsive again, and I am able to regain connectivity. This resets whenever I close the browser.
Log 10 (attached) is a session after re-enabling Adblock.
Log 11 (too large, at: https://drive.google.com/open?id=1oCFVpk0--TOgIZDicyAPdzjyGLJkG9D4 ) is a full session of starting with Adblock installed, leading to the issue; removing Adblock, which fixes the issue; and reinstalling it, which continues without problems.

Deleted: chrome-net-export-log10.json 5.5 MB

chrome-net-export-log10.json 5.5 MB View Download

Not seeing the failure itself in netlog, but I do see that network service experiment is on, and the way extensions hook into network requests is way changed with that, so some regression affecting adblock is pretty believable. 

@dxie: any chance you remember who did the NS port of extensions? Also may be something to keep an eye on, since Adblock is pretty popular.

I'm unable to reproduce on the latest canary. My understanding of the repro instructions are:

1. install adblock
2. navigate to http://jobscan.co
3. try to sign in using linkedin profile
4. navigate a bit

Adding in cduvall@ and cmumford@.

jonproche@, let me know if you can repro on the latest dev. There are quiet a few fixes that went into that release.

Issue with http://jobscan.co seems to be fixed in the latest Canary (71.0.3562.0) but still occurring in Dev (71.0.3554.3), both synced with same extensions including Adblock.
Let me test with other browsing before closing, though, please; navigating to jobscan.co wasn't the only time I encountered the issue, just the quickest way I found to reproduce.

thanks for the feedback. you can also try with the next dev build 3599+.

I'm having this issue too. Also still in latest Canary. I found out that Adblock is the culprit in my case. Disabling Adblock during the Tab hangs, fixes the issue.

Very annoying :-(

See issue 880102.

 Issue 889929  has been merged into this issue.

I have experienced this issue again, seemingly related to Adblock, with browsing unrelated to http://jobscan.co. All tabs hung, then resumed working once removing Adblock in Canary 71.0.3562.0.

Clark, since this bug and the duped  bug 889929  are occurring only with webrequest, can you please take a look? Thanks

 Issue 884174  has been merged into this issue.

Few updates here. It seems that it definitely has to do with adblock. all of the reports thus far have adblock enabled. When doing debugging with the issue reproduced, it seems that the adblock process is hung. I attached the stackshot.

Also to note, all of the reported issues have network service enabled and claimed they cannot repro with network service off. I couldn't accurately repro but all of the time I repro'ed the issue, the network service is on. So it's probably a regression from moving to network service.

The initial stackshot taken looks like the hang is inside v8 code (using https://crsym.corp.google.com/). So it might be we are missing some fields when passing to v8. Clark is doing more investigation here.

Deleted: adblock.txt 752 KB

adblock.txt 752 KB View Download

I haven't been able to repro this, so haven't been able to get very far debugging. If anyone is able to reliably repro this, please let me know.

We are still trying to rootcause the issue. 

In the meantime if you are encountering this issue, disabling the Adblock extension (or turning off the network service experiment in chrome://flags) should mitigate this issue.

ok small update: it looks like a subresource request (just file) is coming to the webrequest handler with -1 for frameId, tabId and parentFrameId. the extension is in a tight look because it somehow this to a different frame whose parents is itself, so it looks infinitely.

we should check what IDs we send in the onBeforeRequest event for subresources, and compare them to non NS path

agh s/tight look/tight loop

Sounds like y'all know what you're doing and looking for, but is there anything for me to do to document or help should I encounter the issue again?
So far, I haven't had the issue since yesterday morning.

Also, literally with clicking "Save changes" I managed to have the issue, and the comment sent once I disabled Adblock and before I could edit :)

I can repro it after navigating a bit, but I'm not sure what triggers it. I have adblock and popup blocker. The issue as pointed out by jam@ is that adblock goes to 100% cpu usage (as seen via task manager), my workaround is to kill the adblock process and restart it, pages load immediately after that

 Issue 889820  has been merged into this issue.

It looks like the reason this is breaking in NS is that we use type = "main_frame" for internal browser requests with NS enabled, while we use type = "other" with NS disabled. I can put up a change to fix this today.

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

commit 9dfe0d894205390137b49d85b440de1d6539772d
Author: Clark DuVall <cduvall@chromium.org>
Date: Tue Oct 02 16:27:58 2018

Reset web_request_type for browser initiated requests

Browser initiated requests were getting the "main_frame" type in the web
request listener details, this gives them the correct "other" type.

Bug:  888672 
Change-Id: Ie5e24c6f51c21ad57babb710e54cc5af47bb02c2
Reviewed-on: https://chromium-review.googlesource.com/1256562
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Commit-Queue: Clark DuVall <cduvall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#595868}
[modify] https://crrev.com/9dfe0d894205390137b49d85b440de1d6539772d/extensions/browser/api/web_request/web_request_proxying_url_loader_factory.cc

Requesting merge for change in comment 32, this is a very safe network service only change.

This bug requires manual review: We are only 13 days from stable.
Please contact the milestone owner if you have questions.
Owners: benmason@(Android), kariahda@(iOS), geohsu@(ChromeOS), abdulsyed@(Desktop)

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

Approving merge for M70. This is behind a flag, and confirmed with jam@ it's a very safe fix. However, please confirm tomorrow in canary as well. 

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

commit 6ffad0c65591148dd4b6e0214caf9290ce4c9d4c
Author: Clark DuVall <cduvall@chromium.org>
Date: Tue Oct 02 16:36:05 2018

Reset web_request_type for browser initiated requests

Browser initiated requests were getting the "main_frame" type in the web
request listener details, this gives them the correct "other" type.

Bug:  888672 
Change-Id: Ie5e24c6f51c21ad57babb710e54cc5af47bb02c2
Reviewed-on: https://chromium-review.googlesource.com/1256562
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Commit-Queue: Clark DuVall <cduvall@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#595868}(cherry picked from commit 9dfe0d894205390137b49d85b440de1d6539772d)
Reviewed-on: https://chromium-review.googlesource.com/1257243
Reviewed-by: Clark DuVall <cduvall@chromium.org>
Cr-Commit-Position: refs/branch-heads/3538@{#816}
Cr-Branched-From: 79f7c91a2b2a2932cd447fa6f865cb6662fa8fa6-refs/heads/master@{#587811}
[modify] https://crrev.com/6ffad0c65591148dd4b6e0214caf9290ce4c9d4c/extensions/browser/api/web_request/web_request_proxying_url_loader_factory.cc

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

Commit: 6ffad0c65591148dd4b6e0214caf9290ce4c9d4c
Author: cduvall@chromium.org
Commiter: cduvall@chromium.org
Date: 2018-10-02 16:36:05 +0000 UTC

Reset web_request_type for browser initiated requests

Browser initiated requests were getting the "main_frame" type in the web
request listener details, this gives them the correct "other" type.

Bug:  888672 
Change-Id: Ie5e24c6f51c21ad57babb710e54cc5af47bb02c2
Reviewed-on: https://chromium-review.googlesource.com/1256562
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Commit-Queue: Clark DuVall <cduvall@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#595868}(cherry picked from commit 9dfe0d894205390137b49d85b440de1d6539772d)
Reviewed-on: https://chromium-review.googlesource.com/1257243
Reviewed-by: Clark DuVall <cduvall@chromium.org>
Cr-Commit-Position: refs/branch-heads/3538@{#816}
Cr-Branched-From: 79f7c91a2b2a2932cd447fa6f865cb6662fa8fa6-refs/heads/master@{#587811}

Tried verifying the fix on the build without fix #71.0.3554.0 on Mac 10.13.6 and Window 10 by followed steps as per comment #0 and comment #9, but unable to observe the difference between both builds. As we are able to browse the site normally. 
Attached the screenshots for reference.
cduvall@ - Could you please help in verifying the fix.

Thanks..!

Deleted: 888672.mp4 7.7 MB

	888672.mp4 7.7 MB View Download

dxie@, could you try to repro on canary? I've never been able to repro this bug.

Screenshots of network log before and after removing Adblock in Dev build 71.0.3559.6.
I haven't been having issues in Canary since my comment on 9/29.

Deleted: 2018-10-03 (1).png 2.2 MB

	2018-10-03 (1).png 2.2 MB View Download

Deleted: 2018-10-03 (2).png 275 KB

	2018-10-03 (2).png 275 KB View Download

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

commit 46965e0a9cc6fd266989af059748c52f060173a6
Author: Clark DuVall <cduvall@chromium.org>
Date: Wed Oct 03 19:35:10 2018

Prevent proxying browser-initiated requests with webRequest in NS

After crrev.com/c/1242296, we no longer need to proxy browser initiated
requests with webRequest. This cleans up the proxy for the
URLLoaderFactory used for browser initiated requests.

Bug:  888672 
Change-Id: I96c55fa5849285ae8f86c4b6d7c24d47c8ac4c19
Reviewed-on: https://chromium-review.googlesource.com/c/1254725
Commit-Queue: Clark DuVall <cduvall@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Cr-Commit-Position: refs/heads/master@{#596324}
[modify] https://crrev.com/46965e0a9cc6fd266989af059748c52f060173a6/chrome/browser/extensions/api/web_request/web_request_apitest.cc
[modify] https://crrev.com/46965e0a9cc6fd266989af059748c52f060173a6/chrome/browser/signin/chrome_signin_proxying_url_loader_factory.cc
[modify] https://crrev.com/46965e0a9cc6fd266989af059748c52f060173a6/content/browser/storage_partition_impl.cc
[modify] https://crrev.com/46965e0a9cc6fd266989af059748c52f060173a6/content/public/browser/content_browser_client.h
[modify] https://crrev.com/46965e0a9cc6fd266989af059748c52f060173a6/extensions/browser/api/web_request/web_request_api.cc
[modify] https://crrev.com/46965e0a9cc6fd266989af059748c52f060173a6/extensions/browser/api/web_request/web_request_proxying_url_loader_factory.cc
[modify] https://crrev.com/46965e0a9cc6fd266989af059748c52f060173a6/extensions/browser/api/web_request/web_request_proxying_url_loader_factory.h

i've tried reproduce this on the latest canary and couldn't repro for 24hrs. This fix should be present on the latest beta and the latest dev push 3569+ builds. let us know if you still see the issue. I'm marking this as verified for now.

Thank you very much!!!