Why would https://codereview.chromium.org/2007223003/ have broken that?  It should have made URLRequestChromeJob::Start() strictly more permissive.

Also, this is not a P0.

Have you confirmed that reverting r396193 locally fixes the bug?  I'm unable to repro the bug in a slightly older build after patching that in.

I am hitting the same issue.

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

commit 4b1fa12663f7169c0868dee60c978acfaa6fd1e2
Author: caseq <caseq@chromium.org>
Date: Wed Jun 01 01:00:00 2016

Revert of Remove obsolete StoragePartition check from old iframe signin path. (patchset #2 id:20001 of https://codereview.chromium.org/2007223003/ )

Reason for revert:
This broke DevTools, please see bug for more details.
BUG= 616282 

Original issue's description:
> Remove obsolete StoragePartition check from old iframe signin path.
>
> BUG= 614808 
> TEST=Signin still works.
>
> Committed: https://crrev.com/1fa5e60dc33595d1bc56f0452370ee66feb544db
> Cr-Commit-Position: refs/heads/master@{#396193}

TBR=anthonyvd@chromium.org,dbeam@chromium.org,creis@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG= 614808 

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

[modify] https://crrev.com/4b1fa12663f7169c0868dee60c978acfaa6fd1e2/chrome/browser/chrome_content_browser_client.cc
[modify] https://crrev.com/4b1fa12663f7169c0868dee60c978acfaa6fd1e2/chrome/browser/chrome_content_browser_client.h
[modify] https://crrev.com/4b1fa12663f7169c0868dee60c978acfaa6fd1e2/content/browser/webui/url_data_manager_backend.cc

> Have you confirmed that reverting r396193 locally fixes the bug? 

Yes. I've played a bit with it and it looks like this CL just triggers a race condition elsewhere by removing thread hopping between UI and IO. If you bring the extra round-trip to UI back, things work.

 Issue 615441  has been merged into this issue.

Thanks for confirming.  That sounds like a bug in Dev Tools that should be fixed, though.  dbeam@ and others have been trying to improve performance in that code, and reintroducing the UI thread hop for this is a regression.

The revert also breaks WebUI behavior in PlzNavigate (--enable-browser-side-navigation), which can't support the (unnecessary) StoragePartition check. (+clamy@)
https://build.chromium.org/p/chromium.fyi/builders/Browser%20Side%20Navigation%20Linux/builds/18992

Here's one plan for moving forward: suppose I land a CL to disable the StoragePartition check but leave the UI thread hop in place for chrome-devtools:// URLs for now, with a big TODO to remove it?  That speeds up chrome:// URLs, fixes PlzNavigate, and should hopefully avoid this race for DevTools, until someone from DevTools can investigate and fix the race.

(Also, is it possible to land a test for the behavior that broke here?  I would have no idea how to write that.)

Oh, interesting note about tests: that's what  issue 615441  was about.  The following tests were failing after my CL landed until the revert (somewhat flakily):
https://build.chromium.org/p/chromium.mac/builders/Mac10.11%20Tests/builds/1712
DevToolsSanityTest.TestNoScriptDuplicatesOnPanelSwitch
DevToolsSanityTest.TestScriptsTabIsPopulatedOnInspectedPageRefresh

I wonder if I can run those on a try bot?

Ah, and thankfully it wasn't flaky.  Just need to find a try bot I can run them on.

thread hopping for just chrome-devtools is fine with me

 Issue 616786  has been merged into this issue.

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

commit f5a831f23ed6fdfed5507e5ce9766a7df5d4203c
Author: creis <creis@chromium.org>
Date: Thu Jun 02 22:24:19 2016

Remove obsolete StoragePartition check from old iframe signin path.

For now, leave the UI thread hop in place for DevTools URLs, due
to  issue 616641 .

BUG= 614808 ,  616282 ,  616641 
TEST=Signin and Mac DevTools still work.

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

[modify] https://crrev.com/f5a831f23ed6fdfed5507e5ce9766a7df5d4203c/chrome/browser/chrome_content_browser_client.cc
[modify] https://crrev.com/f5a831f23ed6fdfed5507e5ce9766a7df5d4203c/chrome/browser/chrome_content_browser_client.h
[modify] https://crrev.com/f5a831f23ed6fdfed5507e5ce9766a7df5d4203c/content/browser/webui/url_data_manager_backend.cc
[modify] https://crrev.com/f5a831f23ed6fdfed5507e5ce9766a7df5d4203c/content/public/browser/content_browser_client.h

This seems to be sticking.  The DevTools tests are passing on the two Mac bots below, and I verified that the DevTools buttons are rendered on Mac Canary 53.0.2757.0.

We can follow up with removing the thread hop for DevTools resources in  issue 616641 .