spurious FetchEvent with illegal destination value "unknown"
Reported by
bke...@mozilla.com,
Apr 12 2018
|
||||
Issue descriptionChrome Version: Version 67.0.3395.0 (Official Build) canary (64-bit) What steps will reproduce the problem? (1)Load https://fetch-event-echo.glitch.me/ (2)Open web console (3)Possibly reload to get more fetch events echoed (4)Look at the fetch events echoed to the web console. What is the expected result? FetchEvents for the document and style sheet should be observed by default. What happens instead? There is an extra FetchEvent with an illegal destination value of "unknown". Note it strangely also has an "only-if-cached" cache mode. sw.js:32 ==> FetchEvent sw.js:34 ==> clientId: "b703f750-e99a-4fda-a78e-896d15d367ef" sw.js:36 ==> request: sw.js:38 ==> method: "GET" sw.js:38 ==> url: "https://fetch-event-echo.glitch.me/" sw.js:38 ==> destination: "unknown" sw.js:38 ==> referrer: "" sw.js:38 ==> referrerPolicy: "no-referrer-when-downgrade" sw.js:38 ==> mode: "no-cors" sw.js:38 ==> credentials: "include" sw.js:38 ==> cache: "only-if-cached" sw.js:38 ==> redirect: "follow" sw.js:38 ==> integrity: "" sw.js:38 ==> keepalive: false sw.js:38 ==> signal: {} sw.js:40 ==> headers: sw.js:42 ==> accept,*/* sw.js:42 ==> user-agent,Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3395.0 Safari/537.36
,
Apr 13 2018
I tried to repro but wasn't able to repro. ==> FetchEvent sw.js:34 ==> clientId: "1033c2c3-fda2-4e88-9f10-a4be70000ef5" sw.js:36 ==> request: sw.js:38 ==> method: "GET" sw.js:38 ==> url: "https://fetch-event-echo.glitch.me/style.css" sw.js:38 ==> destination: "style" sw.js:38 ==> referrer: "https://fetch-event-echo.glitch.me/" sw.js:38 ==> referrerPolicy: "no-referrer-when-downgrade" sw.js:38 ==> mode: "no-cors" sw.js:38 ==> credentials: "include" sw.js:38 ==> cache: "default" sw.js:38 ==> redirect: "follow" sw.js:38 ==> integrity: "" sw.js:38 ==> keepalive: false sw.js:38 ==> signal: {} sw.js:40 ==> headers: sw.js:42 ==> accept,text/css,*/*;q=0.1 sw.js:42 ==> user-agent,Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3395.0 Safari/537.36
,
Apr 13 2018
Hmm. Yea, I can't reproduce it from reloading the page. I guess I only see it when first navigating to the page in a new tab. Can you try these steps: 1. Visit https://fetch-event-echo.glitch.me to get the SW installed. 2. Close that tab. 3. Open a new tab 4. Hit F12 to open web console 5. Load site in tab with web console already open When I do this I get this long string of FetchEvents: ==> FetchEvent sw.js:34 ==> clientId: null sw.js:36 ==> request: sw.js:38 ==> method: "GET" sw.js:38 ==> url: "https://fetch-event-echo.glitch.me/" sw.js:38 ==> destination: "unknown" sw.js:38 ==> referrer: "" sw.js:38 ==> referrerPolicy: "no-referrer-when-downgrade" sw.js:38 ==> mode: "navigate" sw.js:38 ==> credentials: "include" sw.js:38 ==> cache: "no-cache" sw.js:38 ==> redirect: "manual" sw.js:38 ==> integrity: "" sw.js:38 ==> keepalive: undefined sw.js:38 ==> signal: undefined sw.js:40 ==> headers: sw.js:42 ==> accept,text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8 sw.js:42 ==> upgrade-insecure-requests,1 sw.js:42 ==> user-agent,Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36 sw.js:32 ==> FetchEvent sw.js:34 ==> clientId: "77bb80e4-89e8-4ddc-b25e-19d8c264499e" sw.js:36 ==> request: sw.js:38 ==> method: "GET" sw.js:38 ==> url: "https://fetch-event-echo.glitch.me/style.css" sw.js:38 ==> destination: "style" sw.js:38 ==> referrer: "https://fetch-event-echo.glitch.me/" sw.js:38 ==> referrerPolicy: "no-referrer-when-downgrade" sw.js:38 ==> mode: "no-cors" sw.js:38 ==> credentials: "include" sw.js:38 ==> cache: "default" sw.js:38 ==> redirect: "follow" sw.js:38 ==> integrity: "" sw.js:38 ==> keepalive: undefined sw.js:38 ==> signal: undefined sw.js:40 ==> headers: sw.js:42 ==> accept,text/css,*/*;q=0.1 sw.js:42 ==> user-agent,Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36 sw.js:32 ==> FetchEvent sw.js:34 ==> clientId: null sw.js:36 ==> request: sw.js:38 ==> method: "GET" sw.js:38 ==> url: "https://fetch-event-echo.glitch.me/" sw.js:38 ==> destination: "unknown" sw.js:38 ==> referrer: "" sw.js:38 ==> referrerPolicy: "no-referrer-when-downgrade" sw.js:38 ==> mode: "navigate" sw.js:38 ==> credentials: "include" sw.js:38 ==> cache: "no-cache" sw.js:38 ==> redirect: "manual" sw.js:38 ==> integrity: "" sw.js:38 ==> keepalive: undefined sw.js:38 ==> signal: undefined sw.js:40 ==> headers: sw.js:42 ==> accept,text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8 sw.js:42 ==> upgrade-insecure-requests,1 sw.js:42 ==> user-agent,Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36 sw.js:32 ==> FetchEvent sw.js:34 ==> clientId: "6e27f47b-8a27-4ffe-a49b-7045a78ea355" sw.js:36 ==> request: sw.js:38 ==> method: "GET" sw.js:38 ==> url: "https://fetch-event-echo.glitch.me/style.css" sw.js:38 ==> destination: "style" sw.js:38 ==> referrer: "https://fetch-event-echo.glitch.me/" sw.js:38 ==> referrerPolicy: "no-referrer-when-downgrade" sw.js:38 ==> mode: "no-cors" sw.js:38 ==> credentials: "include" sw.js:38 ==> cache: "default" sw.js:38 ==> redirect: "follow" sw.js:38 ==> integrity: "" sw.js:38 ==> keepalive: undefined sw.js:38 ==> signal: undefined sw.js:40 ==> headers: sw.js:42 ==> accept,text/css,*/*;q=0.1 sw.js:42 ==> user-agent,Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36 sw.js:32 ==> FetchEvent sw.js:34 ==> clientId: null sw.js:36 ==> request: sw.js:38 ==> method: "GET" sw.js:38 ==> url: "https://fetch-event-echo.glitch.me/" sw.js:38 ==> destination: "document" sw.js:38 ==> referrer: "" sw.js:38 ==> referrerPolicy: "no-referrer-when-downgrade" sw.js:38 ==> mode: "navigate" sw.js:38 ==> credentials: "include" sw.js:38 ==> cache: "default" sw.js:38 ==> redirect: "manual" sw.js:38 ==> integrity: "" sw.js:38 ==> keepalive: undefined sw.js:38 ==> signal: undefined sw.js:40 ==> headers: sw.js:42 ==> accept,text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8 sw.js:42 ==> upgrade-insecure-requests,1 sw.js:42 ==> user-agent,Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36 sw.js:32 ==> FetchEvent sw.js:34 ==> clientId: "a075d404-82c5-4ba6-9495-ff29baac540f" sw.js:36 ==> request: sw.js:38 ==> method: "GET" sw.js:38 ==> url: "https://fetch-event-echo.glitch.me/style.css" sw.js:38 ==> destination: "style" sw.js:38 ==> referrer: "https://fetch-event-echo.glitch.me/" sw.js:38 ==> referrerPolicy: "no-referrer-when-downgrade" sw.js:38 ==> mode: "no-cors" sw.js:38 ==> credentials: "include" sw.js:38 ==> cache: "default" sw.js:38 ==> redirect: "follow" sw.js:38 ==> integrity: "" sw.js:38 ==> keepalive: undefined sw.js:38 ==> signal: undefined sw.js:40 ==> headers: sw.js:42 ==> accept,text/css,*/*;q=0.1 sw.js:42 ==> user-agent,Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36 sw.js:32 ==> FetchEvent sw.js:34 ==> clientId: null sw.js:36 ==> request: sw.js:38 ==> method: "GET" sw.js:38 ==> url: "https://fetch-event-echo.glitch.me/" sw.js:38 ==> destination: "document" sw.js:38 ==> referrer: "" sw.js:38 ==> referrerPolicy: "no-referrer-when-downgrade" sw.js:38 ==> mode: "navigate" sw.js:38 ==> credentials: "include" sw.js:38 ==> cache: "default" sw.js:38 ==> redirect: "manual" sw.js:38 ==> integrity: "" sw.js:38 ==> keepalive: undefined sw.js:38 ==> signal: undefined sw.js:40 ==> headers: sw.js:42 ==> accept,text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8 sw.js:42 ==> upgrade-insecure-requests,1 sw.js:42 ==> user-agent,Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36 sw.js:32 ==> FetchEvent sw.js:34 ==> clientId: "0d638b40-21df-4c41-913b-bb7d027ed04a" sw.js:36 ==> request: sw.js:38 ==> method: "GET" sw.js:38 ==> url: "https://fetch-event-echo.glitch.me/style.css" sw.js:38 ==> destination: "style" sw.js:38 ==> referrer: "https://fetch-event-echo.glitch.me/" sw.js:38 ==> referrerPolicy: "no-referrer-when-downgrade" sw.js:38 ==> mode: "no-cors" sw.js:38 ==> credentials: "include" sw.js:38 ==> cache: "default" sw.js:38 ==> redirect: "follow" sw.js:38 ==> integrity: "" sw.js:38 ==> keepalive: undefined sw.js:38 ==> signal: undefined sw.js:40 ==> headers: sw.js:42 ==> accept,text/css,*/*;q=0.1 sw.js:42 ==> user-agent,Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36
,
Apr 13 2018
Interesting. In the entries I pasted in #3 the "unknown" destination entries are "no-cache" instead of "only-if-cached". Also, just to clarify, this bug is more about the "unknown" Request.destination value and less about the extra FetchEvents. Its not a value RequestDestination enumeration value: https://fetch.spec.whatwg.org/#requestdestination If the destination is not known by the browser it should be using the empty string.
,
Apr 13 2018
Looks like the code does this:
case WebURLRequest::kRequestContextImport:
case WebURLRequest::kRequestContextInternal:
case WebURLRequest::kRequestContextPlugin:
case WebURLRequest::kRequestContextPrefetch:
case WebURLRequest::kRequestContextServiceWorker:
return "unknown";
Here:
https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/fetch/request.cc?sq=package:chromium&l=606
But thats not a valid value in the webidl:
https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/fetch/request.idl?q=RequestDestination&sq=package:chromium&l=9
,
Apr 16 2018
Thanks bkelly@ for further feedback. I still unable to repro (following steps described #3) but the point you mentioned in #4 and #5 makes sense to me. yhirano@: does it make sense to change "unknown" to "" in Request::destination() ? Or we shouldn't get there in the first place?
,
Apr 16 2018
FWIW, Yoav wrote a spec issue about destination and prefetch: https://github.com/whatwg/fetch/issues/658
,
Apr 16 2018
Apologies for catching up late on this thread. Travel... "prefetch" ended up being an initiator[1] (and haven't landed yet as one). I guess we can align it to "" based on the PR. ServiceWorker should also be aligned to "serviceworker". [1] https://github.com/whatwg/fetch/pull/659
,
Apr 17 2018
This got me wondering if FetchEvent should even be triggered for prefetch: https://github.com/w3c/ServiceWorker/issues/1302 Of course, the FetchEvents I saw could be something other than prefetch.
,
Apr 17 2018
Could the events I saw be kRequestContextInternal triggered from the devtools or something?
,
Apr 24 2018
What about the `null` `clientId`? AFAICT, it should always be a string. I am not sure whether it is possible to not have a specific ID (e.g. how can a `FetchEvent` be handled by a service worker instance if there is no associated client?), but at worse it should be an empty string (according to https://w3c.github.io/ServiceWorker/#fetch-event-clientid), not `null`.
,
Apr 24 2018
I think browsers have been reporting `null` clientId for non-subresource requests until the `FetchEvent.resultingClientId` changes ship. Also, you can totally have a `null` clientId under other circumstances. For example, if a user opens a new tab, types your URL in, and then presses enter, what is the source client? There is none, so the clientId should be null. Similarly, I believe if the source client is cross-origin we do not expose the id.
,
Apr 26 2018
Initial patch to fix this at https://chromium-review.googlesource.com/#/c/chromium/src/+/1029858 bkelly@ - Is there a way to test the "serviceworker" destination bits? (as these requests bypass the SW which we now use for testing...)
,
Apr 26 2018
So, a "serviceworker" destination is not exposed to script: https://fetch.spec.whatwg.org/#requestdestination See the note about it note being observable.
,
Apr 27 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/b57757a125afa56b0bc6373f8d58b4e4c62f0f83 commit b57757a125afa56b0bc6373f8d58b4e4c62f0f83 Author: Yoav Weiss <yoav@yoav.ws> Date: Fri Apr 27 09:01:23 2018 Align Request.destination to spec Currently `Request.destination` is set to "unknown" prefetch, but that was recently changed: Issue: https://github.com/whatwg/fetch/issues/658 PR: https://github.com/whatwg/fetch/pull/659 This CL aligns the destination values to the spec change. Bug: 832105 Change-Id: Ib9f21dcc6cf0ace27b7a810d3670cddc45b3b74f Reviewed-on: https://chromium-review.googlesource.com/1029858 Commit-Queue: Yoav Weiss <yoav@yoav.ws> Reviewed-by: Charlie Harrison <csharrison@chromium.org> Reviewed-by: Yutaka Hirano <yhirano@chromium.org> Cr-Commit-Position: refs/heads/master@{#554341} [modify] https://crrev.com/b57757a125afa56b0bc6373f8d58b4e4c62f0f83/third_party/WebKit/LayoutTests/external/wpt/fetch/api/request/destination/fetch-destination.https.html [modify] https://crrev.com/b57757a125afa56b0bc6373f8d58b4e4c62f0f83/third_party/blink/renderer/core/fetch/request.cc
,
Apr 27 2018
I still see the navigation request as being of "unknown" destination. I'll dig further...
,
Apr 28 2018
It seems these "unknown" values are due to internal, devtools-only requests. I wonder if there's a more appropriate value for such requests.
,
May 22 2018
The devtools FetchEvent may be a dupe of issue #823392 . |
||||
►
Sign in to add a comment |
||||
Comment 1 by bke...@mozilla.com
, Apr 12 2018