+mek, jsbell for follow-up investigation/triage.

Okay, this seems to be harder to fix.
Adjusted expectations (https://crrev.com/c/860004) breaks the tests on Linux (locally tested).

This seems to be a Windows-specific issue:

20:48:00.026 2952 worker/1 external/wpt/FileAPI/url/sandboxed-iframe.html output stderr lines:
20:48:00.026 2952   
20:48:00.026 2952   DevTools listening on ws://127.0.0.1:59341/devtools/browser/75ae4638-d38c-4733-aef8-bad8c3eda026
20:48:00.026 2952   [12848:2892:0110/204741.982:INFO:media_foundation_video_encode_accelerator_win.cc(370)] Windows versions earlier than 8 are not supported.
20:48:00.026 2952   CONSOLE ERROR: line 67: Failed to load blob:null/add2fdad-1aad-4b7e-a112-7dc5af6bb390: Cross origin requests are only supported for protocol schemes: http, data, chrome, https.
20:48:00.030 1492 [31/36] external/wpt/FileAPI/url/sandboxed-iframe.html failed unexpectedly (text diff)

Can we do anything to silence that without rolling back the wpt rollout?
Are there platform-specific expectations?

https://crrev.com/c/860004 will now add it to LayoutTests/TestExpectations as Failure.

Might be related to issue 800898 and flaked on Mac as well now:
https://uberchromegw.corp.google.com/i/chromium.mac/builders/Mac10.11%20Tests/builds/22240

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

commit 4c1abec94b8ccef0ded4c1b110efded89713f5ff
Author: Friedrich Horschig <fhorschig@chromium.org>
Date: Thu Jan 11 11:50:31 2018

Adjust wpt/FileAPI/url/ expectations

This CL adjusts the expectations for the wpt/FileAPI/url/ tests as
reverting the initial change would affect the whole wpt roll out.

TBR=jsbell@chromium.org

Bug:  801078 , 800898
Change-Id: I9b77927562815996f402a4bed91c14dbf23048e3
Reviewed-on: https://chromium-review.googlesource.com/860004
Commit-Queue: Friedrich Horschig <fhorschig@chromium.org>
Reviewed-by: Friedrich Horschig <fhorschig@chromium.org>
Cr-Commit-Position: refs/heads/master@{#528598}
[modify] https://crrev.com/4c1abec94b8ccef0ded4c1b110efded89713f5ff/third_party/WebKit/LayoutTests/TestExpectations

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

commit cc43f5c62e8bd7b3964bffd99871fa0843a415b0
Author: Friedrich Horschig <fhorschig@chromium.org>
Date: Thu Jan 11 17:10:23 2018

Correct name of url-format.any.html TestExpectation

When submitting https://crrev.com/c/860004, the file name contained
"worker" which will be fixed with this CL.

TBR=jsbell@chromium.org

Bug:  801078 
Change-Id: Ia269d99ab051e28b475d2db8fb94cee96f220dca
Reviewed-on: https://chromium-review.googlesource.com/860414
Reviewed-by: Friedrich Horschig <fhorschig@chromium.org>
Commit-Queue: Friedrich Horschig <fhorschig@chromium.org>
Cr-Commit-Position: refs/heads/master@{#528649}
[modify] https://crrev.com/cc43f5c62e8bd7b3964bffd99871fa0843a415b0/third_party/WebKit/LayoutTests/TestExpectations

Sorry for all that flakiness. I guess our situation with blob URLs is even worse/racy than I thought...

(fixing the timeouts in url-format-any.html and url-format-any.worker.html in https://chromium-review.googlesource.com/c/chromium/src/+/861948 fwiw)

Actually, sandboxed-iframe seems to be in a similar situation (becuase it includes url-format.any.js, so I'll re-enable that test as well, as those expectations don't make sense either.

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

commit 3dc9f6270b5a2cfc557a6fab560dae0af51d6d3e
Author: Marijn Kruisselbrink <mek@chromium.org>
Date: Thu Jan 11 23:10:23 2018

Fix url-format.any.js test expectations.

It never failed, so [ Pass Failure ] didn't make sense. It does however
timeout regularly, so reduce the url_count it uses to check if blob URLs
are more or less unique by half.

And since sandboxed-iframe.html includes url-format.any.js, also turn
that test back on, since I'm pretty sure its failures were the same
timeout.

Bug: 800898,  801078 
Change-Id: I90ae00190282ee8915867535dbb39aa171950245
Reviewed-on: https://chromium-review.googlesource.com/861948
Reviewed-by: Joshua Bell <jsbell@chromium.org>
Commit-Queue: Joshua Bell <jsbell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#528802}
[modify] https://crrev.com/3dc9f6270b5a2cfc557a6fab560dae0af51d6d3e/third_party/WebKit/LayoutTests/TestExpectations
[modify] https://crrev.com/3dc9f6270b5a2cfc557a6fab560dae0af51d6d3e/third_party/WebKit/LayoutTests/external/wpt/FileAPI/url/url-format.any.js

Not sure whether this should be a new bug, but the sanboxed-iframe.html flaked again, and this time, it failed:
http://uberchromegw/i/chromium.win/builders/Win7%20Tests%20%28dbg%29%281%29/builds/65749

LOG excerpt:
[...]
05:27:41.567 1400 worker/4 external/wpt/FileAPI/url/sandboxed-iframe.html output stderr lines:
05:27:41.567 1400   CONSOLE ERROR: line 67: Failed to load blob:null/6a935b4d-2a15-45f1-95a0-6b4ae3048751: Cross origin requests are only supported for protocol schemes: http, data, chrome, https.
05:27:41.579 3196 [1745/5675] external/wpt/FileAPI/url/sandboxed-iframe.html failed unexpectedly (text diff)
05:27:41.571 1400 worker/4 external/wpt/FileAPI/url/sandboxed-iframe.html failed:
05:27:41.571 1400 worker/4  text diff
05:27:41.571 1400 worker/4 killing secondary driver
[...]

Could you please take another look?

That stderr output is harmless/expected, and unfortunately it doesn't seem like that bot archives the layout test results, so I don't really have a way of figuring out how it failed...

But I did find at least one failed run on some random other bot, which does have output (https://storage.googleapis.com/chromium-layout-test-archives/WebKit_Mac10_11__dbg_/11989/layout-test-results/results.html), so looking into that now...

Ah, I figured out what is going on... It's more of the same kind of timeouts, but more annoying. sandboxed-iframe.html contains a mix of promise_test and async_tests. Some of these promise tests take quite a while though, so the two async_tests that happen to start before the promise_tests begin then get interuppted by these promise tests, and by the time the promise tests yield back to the async_test the async_test has timed out... I think I'll change the async_tests to promise_tests too to try to eliminate the problem...

Actually that still doesn't make sense, it is some of the sync tests that I'd expect to take a while, not the promise tests, and I think those sync tests should all run before the async tests even start... But at least I can reproduce the issue.

Looking into this more, I think this is a testharness.js bug. Despite our testharnessreport.js setting explicit_timeout: true (thereby telling testharness to not apply any global timeout) something in testharness.js is setting a global timeout anyway...

Oh no, it is my fault... never mind. Fixing.

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

commit 3268e497abcc1362ead4520b312a239043713731
Author: Marijn Kruisselbrink <mek@chromium.org>
Date: Tue Jan 16 21:08:09 2018

Set explicit_timeout to true in nested window test environment in blob URL tests.

This way the tests will timeout when the outer window decides time has
expired, rather than let the nested window decide it earlier.

This mimics the behavior of fetch_tests_from_worker, since
WorkerTestEnvironment always behaves as if explicit_timeout is set to
true.

This should fix spurious timeouts of this test that aren't detected as
timeouts by our test runner (and specifically cases where we don't
actually consider the test as timed out).

Bug:  801078 
Change-Id: I3a884bd746afcefd5cbe5008db7df4a609eb0044
Reviewed-on: https://chromium-review.googlesource.com/865002
Commit-Queue: Victor Costan <pwnall@chromium.org>
Reviewed-by: Victor Costan <pwnall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#529500}
[modify] https://crrev.com/3268e497abcc1362ead4520b312a239043713731/third_party/WebKit/LayoutTests/external/wpt/FileAPI/url/sandboxed-iframe.html

Okay, hopefully that really fixed this...