Hello, here are the day 1 meeting notes from the service worker F2F. The
attendees are CC'd if there are any corrections that need to be made or if
anyone has any questions or concerns that they would like to raise.
=========================================
Service Worker F2F
April 11, 2016
Attendees:
-------------------------
* Microsoft - Ali Alabbas, Jatinder Mann, Adrian Bateman, Travis Leithead
* Google - Joshua Bell, Matt Falkenhagen, Jake Archibald, Alex Russell,
Marijn Kruisselbrink
* Mozilla - Ehsan Akhgari, Ben Kelly
* Samsung - Jungkee Song
* Apple - Ted O'Connor
Agenda:
-------------------------
* Vendor comments on general direction
* v1 issues
Vendor comments on general direction (e.g. Tim’s comment)
-------------------------
* Service workers are overly complicated for simple use cases
* Ted O’Connor: don't worry about Tim's comment
* Matt Falkenhagen: Average time for starting up SW when a fetch is
registered is 150 ms
v1 Issues:
-------------------------
* #861: be more explicit that jobs always run asynchronously
* Already implemented this way in Gecko, but would be nice to have it be
part of the spec
* Spec originally allowed register to run sync, but need to be consistent
* Don't want to spawn new jobs and have jobs running in parallel (we want
to have one job queue)
* Resolution: update spec language to ensure that all jobs are scheduled
asynchronously
* #850: FetchEvent.respondWith does something weird with the body of a
response
* Streams need to be figured out (pipeTo algorithm)
* In the meantime, some steps have been put in place until everything is
spec'd in Fetch
* Consuming body input to the API so that scripts can't read after that
* Comment from Yushino from Google who was working on Streams: pipeTo
transfers the object via teeing
* We probably don't want to tee because we want to consume data
* Outcome: wait and see then change the spec with what is required to
accommodate changes from Fetch API
* #848: "Wait for all the tasks queued by Update State" language is
problematic
* #851: Install algorithm step 14 should clear waiting worker before
updating state to redundant
* #860: spec should queue tasks to expose attribute changes on ServiceWorker
and ServiceWorkerRegistration
* Queuing task per execution environment
* Expectation is that the attributes are in a certain that state
* There may always be a race between getters
* Fully deterministic way for getters in this fashion is via event
listeners
* Bug in Gecko: registration.installing and activating currently returns
null
* Outcome: queue a task to update these values per context, when the
state changes.
*
https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#update-state-algorithm
- this should queue a task to update the serviceWorker.state objects, and the
registration.waiting (etc) objects.
* In the updatefound listener, reg.installing should always be the new
worker, even if there's no install event.
* In the statechange listener, the registration should be updated.
* #816: ExtendableMessageEvent.source cannot be SameObject
* Outcome: update spec reflecting IDL changes
* Related issue filed in IDL - no update now, will ping
* #810: MessagePort[] no longer valid in WebIDL
* Resolution: spec needs to be updated
* #870: Inconsistencies due to when clients are created
* When opening a new tab, Chrome (in initial fetch event) there will be a
client there and in Mozilla there isn't
* Potential client ID can be used to provide information about what the
client is if it's not created yet
* Want to have a rich Fetch event that can include if it was a soft/hard
reload
* Once it's in the history and doesn't show up in client lists, the
document shouldn't exist anymore
* No client is created for content-disposition downloads
* This is a reason for just using potential client ID rather than
re-using the client ID
* What do you want to do with a client before it's created?
* Developer may want to cater the content to fill in the client based
on the window size
* Do we create a client before the request goes through even if the
client does not end up being used?
* Don't update service worker if there is a reload of a page since there
is no moment when the client is disengaged from being controlled by the service
worker
* For window.open, about:blank inherits the creator (i.e., it is
controlled)
* We are already committed to having a potential client if we have a
potential client ID, so we should be able to introspect that client in the
clients list
* about:blank is the url of the reserved (potential) client
* Resolution: have client ID and potential client ID, clients.matchAll
will not return all clients by default unless you pass in a flag that will
return the potential client
* get will give back the client if a potential client ID is passed in
* Sub-workers: parent worker would be the client
* Outcomes:
* A reserved client is created for a navigation
* fetchEvent.clientId - represents the client that initiated the
request
* fetchEvent.reservedClientId - represents the client that has been
created for potentially-client-creating request, which may not be used in the
event of a redirect, content-disposition, network error, or other response
rejection
* fetchEvent.targetClientId - the id of the client that the new client
will replace if it's used
* clients.matchAll() will not return reserved clients
* clients.matchAll({ includeReserved: true }) will return reserved
clients
* Reserved clients will have url about:blank
* Reserved clients will inherit visual properties from their target
client (which may be a cross origin client, or new tab)
* client.used will be false for reserved clients
* clients.get will return a reserved client
* postMessage on a reserved client will be buffered
* Some of the naming is up for bikeshedding, specifically:
* "reserved", in all the properties it's used
* targetClientId or replacesClientId - intent is to know which client
* client.used
* #787: what should the document base URI for an intercepted navigation
* Being consistent is helpful: use response.url as the base
* Request url would still be reflected in the location bar
* Being able to change the base should be for v2
* If someone wanted to change the location bar, they can do a redirect
* Outcome: use response.url as the base
* Need to investigate if this breaks any behavior
* #771: Allow waitUntil to be called multiple times, async
* Already agreed on, rough algorithm outlined by Jake and needs to be
reviewed
* Want to allow this to all ExtendableEvent but respondWith should be
called with the event dispatch (synchronously)
* #769: ServiceWorkerContainer.controller prose says to return undefined,
but the IDL doesn't allow that
* If in the secure context, it is not in the type system
* Outcome: the spec needs to be updated to reflect that the property
won't exist in non-secure contexts
* #765: serviceworker for iframes with srcdoc
* #754: Make secure context requirements more explicit
* Issues filed in HTML spec to resolve issue
* Outcome: update spec as property won't exist in non-secure contexts
* Need to also make sure that SW doesn't work for file:// urls
* Outstanding question: Should navigator.serviceWorker be there for
file:// origins?
* Asking Anne for further feedback
* #764: getRegistration IDL is wrong
* Note: about:blank is in the secure context
* No further action taken
* #737: Make the Cache API deal with request's redirect mode not being
"follow"
* Issue closed, no further action required
* #732: Remove frameType, maybe add ancestorOrigins
* Is there any way that you can walk the window hierarchy?
* Does xframe options modify it?
* What does sandbox do?
* Outcome: adding ancestorOrigins is fine as long as you already get this
information
* frameType is still useful for "auxiliary" (which can't be determined
from ancestorOrigins)
* #728: When does the openWindow promise resolve?
* Outcome: keep resolution as before with startMessages proposal since
event listeners are not ideal in this situation
* #710: spec should be more explicit about accessing internal body on opaque
Responses
* We should do what fetch does here - if fetch disallows "no-cors" HEAD
requests, cache.match shouldn't generate them from opaque responses
* Outcome: it appears that fetch does allow it - issue created in fetch
spec: #278: should fetch() allow no-cors cross-origin HEAD request?
* #703: Receivers of ranged responses must ensure all ranges come from the
same underlying resource
* Research is needed for the following:
* What do browsers do today without SW when it comes to 200 responses
to a ranged request?
* Is returning a 200 response for a 4GB video a reasonable thing to do
for performance?
* Multiple ranges can be provided - do browsers support this?
* Outcome: more research is required before proceeding
* #699: Restrict openWindow() to http(s) schemes?
* Should be able to open about:blank since users are able to do redirects
to there anyways
* The use case is not clear, but this is more about why we're restricting
it
* Allowing about:blank means figuring out what origin it is, and if it's
service-worker controlled - it's more complicated than it seems, and it's a
real edge case
* Outcome: move this to v2 as it is currently already disabled and it
would be easier to enable later on
* #688: Define the lifetime of a blob URL created inside a service worker
* createFor was made so that blob URLs could be auto-revoked so that
after it was used once, it would be de-referenced
* Outcome: already agreed on but just needs spec changes - Marjin will
look into making the necessary spec changes to hide the URL.createObjectURL,
URL.createFor, and URL.revokeObjectURL APIs from service workers
* #851: Install algorithm step 14 should clear waiting worker before
updating state to redundant
* Queuing in the right order would make the event fire less
* See #848 and #860 above
* Outcome: update attributes before firing events
* #857: if service-worker-allowed header changes should active worker be
potentially unregistered?
* Do not unregister due to the service-worker-allowed header
* Nothing special that will be done for this case, it will just fail
the update
* Outcome: Clear Site Data is the kill-switch that we want (being
developed here: https://w3c.github.io/webappsec-clear-site-data/)
* #854: Access to fragment identifiers
* Caches should ignore the fragments (stored but not matched)
* Outcome: add fragments to request & response urls. Cache API will store
them, but will ignore them when matching.
* Our intention is that the fragment in a response.url for a navigation
will not be used to scroll the page - only the request url can do that
* #677: Client.postMessage should return a Promise
* Can accomplish this using a library by sending a postMessage back
* Outcome: resolved - it isn't worth changing for this one instance of
postMessage
* #672: matchAll() runs Request constructor off the main thread
* We don't have a way to specify that tasks run before or after
* Move constructor out of "in parallel" and not worry about timing
* Outcome: resolved - move the "if request is a string, upgrade to
request" steps to before "run in parallel"
* #873: Drop isReload
* Would it be useful to know when the user has done a hard reload?
* isReload would help differentiate between user-initiated or dev tools
no-cache
* If someone hits reload it sets Request no-cache which is observable on
FetchEvent.request
* Outcome: resolved - we can drop isReload if we can get the right
information out of .cache
* #793: navigations that are not intercepted should still allow interception
on further redirects
* When there is a navigation that is not intercepted by a service worker,
a new request is not created for redirects
* New request needs to be set for navigation with manual redirect
* Outcome: resolved - unhandled navigation requests that result in a
redirect should go back through the SW
* #719: "no-cors" CSS SOP violation
* Outcome: inconclusive - security team needs to be consulted
* #266: Referrer policy: Should request's referrer policy be updated in the
main fetch?
* How referrer policy interacts when it goes through a SW
* Fetch referrer-policy is used instead of what is issued by the service
worker
* Mozilla has already implemented
* This is an acceptable change
* Outcome: resolved - we agree to the change since
event.respondWith(fetch(event.request)) should behave as much as possible as if
the SW wasn't there
Please let me know if you have any questions or concerns.
Thank you,
Ali
