New issue
Advanced search Search tips

Issue 721874 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Aug 2017
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Navigation preload should not abort in a way that's observable to JS

Project Member Reported by jakearchibald@chromium.org, May 12 2017

Issue description

1. Visit https://jaffathecake.runkit.io/5915ff685662e900117e6e32/branches/master/ to install the service worker.
2. Refresh the page to confirm navigation preload is enabled. It should respond "Received preload request".
3. Enable "Preserve log" in devtools
4. Navigate to https://jaffathecake.runkit.io/5915ff685662e900117e6e32/branches/master/slow/.

Code for the test: https://runkit.com/jaffathecake/5915ff685662e900117e6e32.

I see "Preload response rejected!" in the log. It seems like Chrome is aborting the preloadResponse because I don't use it in the response, but the spec doesn't say this should happen.

Practically, developers may want to respond from the cache, but use the preloadResponse to populate the cache for next time, in a kind-of stale-while-revalidate model, but Chrome's current behaviour prevents this.

I think it's good that Chrome aborts responses that aren't needed, but this should be done when event.preloadResponse is GC'd, so the abort isn't observable by JS.
 

Comment 1 by horo@chromium.org, May 15 2017

Owner: horo@chromium.org
Status: Assigned (was: Untriaged)
I dug into this a little more. If you use waitUntil, you don't get the error, which is kinda a reasonable thing to require.

Chrome's behaviour here seems a ton more reasonable in light of that. We may want to spec it. However, we should spec it in terms of fetch cancelation, and ensure it rejects in the correct way.

Comment 3 by bke...@mozilla.com, May 15 2017

Is it possible to write a WPT to cover this situation?
I have one almost ready to go - it's how I discovered the waitUntil difference.

Comment 6 by horo@chromium.org, May 16 2017

Labels: di
Status: ExternalDependency (was: Assigned)

Comment 7 by horo@chromium.org, Jul 3 2017

Labels: -di
Status: WontFix (was: ExternalDependency)
Seems to me the conclusion is to spec Chrome's behavior and add the WPT test at https://github.com/w3c/web-platform-tests/pull/5921, so there's no actual required on this bug.

Sign in to add a comment