Dev console screenshot

Deleted: Screen Shot 2018-05-30 at 12.10.29 PM.png 218 KB

	Screen Shot 2018-05-30 at 12.10.29 PM.png 218 KB View Download

Thanks for the report!  Taking a look to see if it's a Site Isolation bug.  So far, I can repro on Windows Stable (67.0.3396.62) with Site Isolation.  I cannot repro on Mac Stable (67.0.3396.62), nor Windows Canary (69.0.3445.0) or Windows Dev (68.0.3438.3) all with Site Isolation enabled.

I'll see if we can confirm if the bug goes away with Site Isolation disabled.  (You can also try using the steps at https://www.chromium.org/Home/chromium-security/site-isolation#TOC-Diagnosing-Issues.)

When it does fail, it appears to be a blob: URL that isn't working.

Note: issue only happens with latest market version of chrome 67.0.3396.62
It is not reproducible in the previous versions

Thanks.  I just got the bug to repro on Mac stable in a different profile, and it repros both with and without Site Isolation.  Thus, I don't think it's a Site Isolation bug.

mek@, do you know any blob URL changes in the M67 timeframe that might have affected this, or who might know?  I suspect a field trial might be involved, since I see it repro in some of my Mac profiles but not others.

Hmm, now it's repro'ing pretty consistently for me on Mac Stable, so it could be either a race condition or a high percentage field trial.

CC'ing govind@, since this might be considered an important bug to fix for M67.  A bisect seems useful for finding where it was fixed in M68, since maybe we can just merge the relevant CL to M67.

+pbommana@, could you pls bisect this?

Tagging as M67 "RBS" for tracking purpose.

None of the blob URL changes I know of should have had any effect on the behavior in M67. More generically, we fixed some of our logic around evicting blobs to disk in M67, but that really shouldn't have caused any issues here either. None of the other blob related changes stand out to me either...

Reproduces on linux too for me fwiw, so I'll do a bit more digging to see what's going on.

There seems to be some ordering issue going on here, where somehow the blob URL is revoked before the fetch is started in the browser process. Not sure if anything with fetch scheduling changed in M67? The blob code (until the rewrite I mentioned in comment 8 shippes) relies on all blob URL fetches to be syncronously dispatches as IPC/channel associated mojo calls to the browser process.

I suspect this might be caused by the RendererSideResourceScheduler field trial? That at least seems like it first launched in M67, and without knowing anything about what it does it sounds like it could cause problems like this.

Yep, running chrome with --disable-features=RendererSideResourceScheduler makes this work again for me.

Based on offline chat with mek@ and based on comment#12, removing needs-bisect label.

Thank you mek@. 

Based on comment #11, would it be ok and possible to disable "RendererSideResourceScheduler" via Finch for M67 stable if this has wider impact?

I cannot reproduce the issue -maybe because I live in Japan, I'm redirected to https://www.filmstruck.com/unavailable/. Do you have any recommendation how to reproduce the issue?

Not sure about how to reproduce the observed issue, but what appears to be happening is that under some circumstances the renderer delays sending the request for the blob URLs to the browser, but unfortunately those circumstances don't seem to ever happen during layout tests, as that would have let us catch this earlier. I'm not sure how the scheduler stuff decides when to throttle subresource requests, but until blob URL mojofication lands it is never safe to delay fetching a blob URL as the website might immediately revoke the URL after initiating a fetch, and expect the fetch to still work.

mek@, can you try with https://chromium-review.googlesource.com/c/chromium/src/+/1080349 ? I'll disable the switch via finch...

@yhirano
The issue is no longer reproducible on the noted website because it was fixed by the webdev team with an update pushed to the servers. This is still worth looking at as many other websites and services may be impacted by this chrome update change.

Based on #19 removing RBS.

Throttling is enabled until <body> begins, so I expect that is rare, but I may be wrong.

Thank you yhirano@. 
We won't block M67 further roll out based on #20 but pls have CL ready to disable via Finch just in case if needed in future.

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

commit 1a7cd4c26cdca76a627db82a6f423446baced1d0
Author: Yutaka Hirano <yhirano@chromium.org>
Date: Fri Jun 01 03:50:55 2018

Do not throttle non-http[s] requests

Bug:  847890 
Change-Id: Idde0768ef78a23b7082e1b19cad35c683d5e6c20
Reviewed-on: https://chromium-review.googlesource.com/1080349
Commit-Queue: Yutaka Hirano <yhirano@chromium.org>
Reviewed-by: Marijn Kruisselbrink <mek@chromium.org>
Cr-Commit-Position: refs/heads/master@{#563525}
[modify] https://crrev.com/1a7cd4c26cdca76a627db82a6f423446baced1d0/third_party/blink/renderer/platform/loader/fetch/resource_loader.cc

Your change meets the bar and is auto-approved for M68. Please go ahead and merge the CL to branch 3440 manually. Please contact milestone owner if you have questions.
Owners: cmasso@(Android), kariahda@(iOS), bhthompson@(ChromeOS), abdulsyed@(Desktop)

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

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

commit ba6939162b4f62ac1dfc43f2349337fb04a33ac8
Author: Yutaka Hirano <yhirano@chromium.org>
Date: Mon Jun 04 01:09:57 2018

Do not throttle non-http[s] requests

TBR=yhirano@chromium.org

(cherry picked from commit 1a7cd4c26cdca76a627db82a6f423446baced1d0)

Bug:  847890 
Change-Id: Idde0768ef78a23b7082e1b19cad35c683d5e6c20
Reviewed-on: https://chromium-review.googlesource.com/1080349
Commit-Queue: Yutaka Hirano <yhirano@chromium.org>
Reviewed-by: Marijn Kruisselbrink <mek@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#563525}
Reviewed-on: https://chromium-review.googlesource.com/1084142
Reviewed-by: Yutaka Hirano <yhirano@chromium.org>
Cr-Commit-Position: refs/branch-heads/3440@{#127}
Cr-Branched-From: 010ddcfda246975d194964ccf20038ebbdec6084-refs/heads/master@{#561733}
[modify] https://crrev.com/ba6939162b4f62ac1dfc43f2349337fb04a33ac8/third_party/blink/renderer/platform/loader/fetch/resource_loader.cc

Hi govind@, I'd like to merge 1a7cd4c26cdca76a627db82a6f423446baced1d0 to stable. Should I wait for a beta containing ba6939162b4f62ac1dfc43f2349337fb04a33ac8 to be released first?

This bug requires manual review: Request affecting a post-stable build
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), govind@(Desktop)

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

Chatted with govind@; I retract the request because we can disable the feature via finch when more sites are suffering.

Tested the issue on reported chrome version# 67.0.3396.62 using Ubuntu 14.04 with steps mentioned below:
1) Launched chrome reported version and navigated to URL: watch.filmstruck.com
2) Opened Devtools > Console
3) seen below errors in console:
Failed to load resource: the server responded with a status /favicon.ico:1 of 406 (Not Acceptable)
Failed to load resource: the server responded with a watch.filmstruck.com/:1 status of 406 (Not Acceptable)

@Yutaka Hirano: Please find the attached screencast for your reference and let us know if we missed anything in verifying the fix and help us in confirming the fix.

Thanks!

Deleted: 847890.ogv 1.7 MB

	847890.ogv 1.7 MB View Download