Re: [service worker] f2f meeting notes, next meeting details

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

Received on Tuesday, 12 April 2016 06:44:55 UTC