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

Here are notes I captured during the meeting:


Service Workers Face-to-Face Meeting Notes

Date: January 26, 2016
Place: Mozilla's San Francisco office

Attendees
--------------
 * Microsoft - Ali Alabbas, Jatinder Mann
 * Google - Jake Archibald, Alex Russell, Ilya Grigorik, Marijn Kruisselbrink
 * Mozilla - Anne van Kesteren, Benjamin Kelly
 * Apple - Edward O'Connor
 * Samsung - Jungkee Song
 * Conrad Irwin


Agenda
----------
 * Discuss outstanding version 1 spec issues from GitHub 
 * Cache API enhancements, especially transactions and making addAll more useful
 * Foreign fetch
 * Navigation handling


Spec Issues
---------------
 #814: should subresource FetchEvents trigger an update if 24-hours since last check?
     * Resolved: FetchEvents should be treated like other ExtendableEvents with the 24-hour check update
 #813: Should mixed content always be blocked?
     * Resolved: allow passthrough of mixed content and adding it to the cache. We should also look at persisting mixed content warnings until storage is cleared.
 #808: What is FetchEvent.clientId for navigation requests
     * Resolved: pages are explicitly closed by user action so it makes sense to have it be null. Also, on navigation or close the client should not be gettable.
 #800: should update() during top level script evaluation be ignored?
     * Resolved: single job queue for register(), update() and soft update (as they are classified as equivalent jobs). So, update() from the installing worker of a new registration is rejected with InvalidStateError
     * Benjamin Kelly will review to make sure this is no longer an issue
 #788: should update on navigation or the subsequent updatefound event be delayed until document DOM is loaded?
     * Resolved: add a note to the spec to delay triggering of an update until after DOMContentLoaded of the associated page. If it’s a worker, don’t update until after the worker script has run.
     * Specifically, Chrome's implementation tries to schedule the updates after the worker stops
          * Schedule an update 1 second after page load for a navigation in a SW's scope.
          * Whenever the active worker stops, if it hasn't attempted an update in 24 hours, and no update is scheduled, schedule an update.
          * If the active worker has been running without stopping for 5 minutes, if hasn't attempted an update in 24 hours, and no update is scheduled, schedule an update.
 #787: what should the document base URI for an intercepted navigation
     * Requires further investigation. Jake to write a blog post to ask developers if we can safely make this change – showing both CSS and the document and asking where links and the background images would go.
 #783: Race when registering multiple service workers for the same scope
     * Resolved: having a single job queue where register/update/unregister jobs are scheduled in FIFO order. Same job is aggregated when scheduled. Allow the installing worker finish installing or eventually timeout, allowing the next SW in queue
     * Timeouts in Blink: 30 seconds for executing sync JS (e.g. while(true)), five minutes for any event - e.g. event.waitUntil(new Promise())
 #771: Allow waitUntil to be called multiple times, async
     * Resolved: it would be useful to support this especially when a promise doesn’t resolve before returning to the event loop since waitUntil needs to be called before returning to the event loop - requires specifying
 #757: passthrough service worker can break sites using redirected stylesheets
     * Synthetic responses from service workers - e.respondWith(fetch(e.request)) - will assume the request url (i.e., when there's no response url). Thus, navigation will not be affected since it doesn't look at the response url, but stylesheets will be fixed and other workers will get the same behavior.
 #737: Make the Cache API deal with request's redirect mode not being "follow"
     * Requires further investigation
          * We should be able to store opaque redirects when redirect mode is not “follow” (not return an error) so that the original site doesn’t need to go to the network and can instead pass on to another service worker
          * E.g. cache.add(redirectingNavUrl, { mode: 'same-origin', redirect: 'manual' }) stores an opaque redirect
 #728: When does the openWindow promise resolve?
     * Resolved with the following:
          * We should buffer messages until startMessages is invoked
               * Page onload invokes startMessages
               * Assignment to navigator.serviceWorker.onmessage invokes startMessages
               * Invocation of navigator.serviceWorker.startMessages() invokes startMessages
          * No change on when openWindow resolves
 #718: Proposal: Optimized No-Fetch Service Workers
     * Resolved: check which event listeners have been registered via addEventListener and optimize based on that - additionally, addEventListener should throw an error if it’s called after the initial execution of the script (e.g. in an event handler) 
     * Extremely useful for optimizing push-only scenarios
 #704: How to deal with cookie bombing
     * Resolved: this can be dealt with via https://w3c.github.io/webappsec-clear-site-data/ - it is up to the server to return this when there are too many or too large cookies
 #703: Receivers of ranged responses must ensure all ranges come from the same underlying resource
     * Cache.put should prevent adding 206 responses
     * HTTP spec says a server can respond 200 in response to a ranged request
          * Do browsers allow this?
               * If not, we will have to file bugs
          * If browsers do not fix, we can change cache.match
 #699: Restrict openWindow() to http(s) schemes?
     * No resolution - it would seem appropriate that openWindow should accept the same set of URLs as window.open
 #688: Define the lifetime of a blob URL created inside a service worker
     * Resolution: do not expose createObjectURL in service worker scope as there is no clear use case for it
 #677: Client.postMessage should return a Promise
     * No resolution - it would help to return a promise for client.postMessage as a way to acknowledge that the message was received on the other end, however, it would break away from the current paradigm where postMessage does not return a promise when called in other contexts



-----Original Message-----
From: Chaals McCathie Nevile [mailto:chaals@yandex-team.ru] 
Sent: Tuesday, February 9, 2016 7:22 AM
To: public-webapps WG <public-webapps@w3.org>
Subject: [service worker] f2f meeting notes, next meeting details

Hi folks,

for those who are wondering, the last face to face meeting created an agenda, as a github issue:  
https://github.com/slightlyoff/ServiceWorker/issues/806 and then just updated issues as they went. The relevant sisues are linked from teh agenda, so you can look for updates from around January 26, but as far as I am aware there are no actual notes available from the discussion :(

There will be another face to face meeting to discuss service workers, hosted by Microsoft in Seattle or Redmond, on 11-12 April. Right now there is a stub page for the meeting:  
https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/11-12aprSW.md


To register for the meeting, or request agenda or remote attendance please make a pull request on that page or in reply to this thread on the email list.

cheers

Chaals

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
  chaals@yandex-team.ru - - - Find more at http://yandex.com

Received on Wednesday, 10 February 2016 00:52:33 UTC