Open jakearchibald opened 6 years ago
The latest agreement on FetchEvent (https://github.com/w3c/ServiceWorker/issues/1091#issuecomment-311023682):
clientId
: The client that initiates the request.resultingClientId
: The potentially-reserved client that will house the resulting document/worker.replacesClientId
: an existing client that will be replaced, or have its document replaced https://github.com/w3c/ServiceWorker/issues/1091#issuecomment-311325493Proposal of not exposing reserved clients: #1216.
We are here now. I'd like to discuss:
Issues:
@jungkees cheers! I've added the stuff I've been looking at so far to the OP. I'll merge yours into that.
I'm sweeping through open issues today.
We're trying to implement https://github.com/whatwg/fetch/pull/146 and ran into a potentially thorny spec issue in https://github.com/whatwg/fetch/pull/146#issuecomment-341710548. Might be worth talking about in person.
How do people feel about discussing “meaningless” Accept
headers like */*
for images in Firefox that make dealing with such requests in Service Workers hard and encourage relying on file extensions, especially as there is no consistency among how browsers deal with this.
How do people feel about discussing “meaningless” Accept headers like / for images in Firefox that make dealing with such requests in Service Workers hard and encourage relying on file extensions, especially as there is no consistency among how browsers deal with this.
We can discuss it, but standardizing Accept headers is a bit orthogonal to service workers. I recommend raising a fetch spec issue to investigate alignment between browsers on Accept headers.
While it applies to Ajax situations like fetch
and XMLHttpRequest
, the issue applies to all other static “fetching” scenarios as well, be it link
, img
, a
, etc. Dealing with it in the context of the Fetch API alone seems too limited, at least from my point of view.
@tomayac the fetch spec deals with all browser fetching, not just the fetch API.
I've moved the push API stuff to the morning, so @beverloo can join.
All spec'd browser networking loading goes through the fetch specification (modulo old specs not updated yet). Not just the fetch()
API.
Thanks both for the clarification. I guess fetch spec issue(s) is the way to go then.
Planning to start around 09:00 tomorrow.
Sorry to miss this F2F. Have a really nice and productive session!
@wanderview points out that we would benefit from better tests for the cache API.
Action: Add notes about cache sizes + opaque responses. But diversity in mitigation is welcome.
Action: Built a test that creates a same-origin worker, but in the service worker fetch a response from another origin. According to the spec it should work, and the base url should be the response url. If it fails, @wanderview would be interested in adding that failing to the spec.
Location
TPAC, Burlingame.
Agenda
Push API
I don't know the details, but I believe the Safari folks have some concerns around the push API, so let's go through that first, timeboxed to an hour.
Changes & bugs
InstallEvent
? It doesn't do anything beyondExendableEvent
now.sw.register()
toLink
headerServiceWorker#postMessage
Interesting feature requests
Clients.matchAll()
should exclude the current environment - OR SHOULD IT? (sorry)Clients.matchAll()
navigation
event - only if there's a 'champion' in the room