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

   * 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

   * 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 
   * #850: FetchEvent.respondWith does something weird with the body of a 
      * 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 
   * #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 
      * Bug in Gecko: registration.installing and activating currently returns 
      * Outcome: queue a task to update these values per context, when the 
state changes.
 - 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 
      * 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 
      * For window.open, about:blank inherits the creator (i.e., it is 
      * 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 
         * 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 
         * 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 
         * 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 
      * 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 
      * 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 
         * 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 
      * 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 
      * 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 
   * #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 
      * If someone hits reload it sets Request no-cache which is observable on 
      * 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 
      * 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,

Reply via email to