Create F2F agenda - 25 October 2018

[jatindersmann]

Where

Location: TPAC, Lyon, France.
When: 9AM, October, 25, 2018

Minutes

• https://www.w3.org/2018/10/25-serviceworker-minutes.html

Attendance

Please let us know if you're planning on attending the F2F meeting.

Agenda

The agenda is subject to change reflecting the progress of the work. Please update it if you notice things outdated or missing.

Implementer update

Share implementation status and issues, performance issues, compatibility issues, etc.

• Discuss on the concerns Safari folks had around the push API.

Changes & bugs

• Multiple service worker instances
  • Allowing multiple worker threads: consider allowing multiple worker thread instances for a single registration #756.
  • Exposing mulitple instances via DOM: thoughts on exposing multiple-instances to sites via the DOM #1185.
  • Using separate instances for each functional event: consider allowing multiple worker thread instances for a single registration #756 (comment).
• Service worker resurrection
  • Should we ditch resurrection?: resurrected service workers don't fire an activate event which may break expectations #1204.
  • Behavior of ready promise when controlling rgistration is resurrected: ready promise doesn't work right when controlling registration is resurrected #1198.
• ready promise weirdness
  • ready promise is kind of weird with overlapping scopes: ready promise is kind of weird with overlapping scopes #1278.
  • ready promise is kind of weird after you call unregister(): ready promise is kind of weird after you call unregister() #1279.
• Does changing updateViaCache mint a new ServiceWorkerRegistration or update them all?: Does changing updateViaCache mint a new ServiceWorkerRegistration or update them all? #1189. This is being implemented. We need to help them by working on the corresponding part of the spec.
• FetchEvent.navigationLoadType: Proposal: FetchEvent.navigationLoadType #1167. The spec and the implmentations are underway. We need to review them.
• Is the browser required to start the ServiceWorker for postMessage() if there is no message event handler?: is the browser required to start the ServiceWorker for postMessage() if there is no message event handler? #1200, Nerfing all events on all event targets in a serviceworker after initial script evaluation seems odd whatwg/dom#371 (comment).
• Async waitUntil microtask issue: async waitUntil microtask issue #1213.
• "no-cors" CSS SOP violation: "no-cors" CSS SOP violation #719.
• What happens to the request body if the fetch isn't handled?: What happens to the request body if the fetch isn't handled? #1191.
• Exposing the identity of service workers and a clients: Find a way for service workers to get their current state #1077, Expose environment ids? #643.
• "Unregister" operation may be interrupted by ServiceWorker#postMessage: "Unregister" operation may be interrupted by ServiceWorker#postMessage #1146.
• Should a service worker be allowed to register new service workers?: Should a service worker be allowed to register new service workers? #1117.
• What happens if an initial about:blank inherits a controller, but its navigation request does not match any service worker?: what happens if an initial about:blank inherits a controller, but its navigation request does not match any service worker? #1232.
• Should Client.navigate() reject on uncontrolled clients?: should Client.navigate() reject on uncontrolled clients? #1254.
• updatefound event in service worker context seems unreliable: updatefound event in service worker context seems unreliable #1255.
• Should blob URLs inherit controller from parent environment or environment that called createObjectURL: should blob URLs inherit controller from parent environment or environment that called createObjectURL()? #1261.
• Should local URLs check origin before inheritting a controller?: should local URLs check origin before inheritting a controller? #1262.
• Should a SW client.id persists across Discards/Reloads of the same page?: Should a SW client.id persists across Discards/Reloads of the same page? #1263.
• Scope matching algorithm breaks sites that don't end in a slash: Scope matching algorithm breaks sites that don't end in a slash #1272.
• Should the worker be removed from the registration before its state is set to "redundant"?: Should the worker be removed from the registration *before* its state is set to "redundant"? #1273.
• The Cache objects do not expire unless authors or users delete the entries.: The Cache objects do not expire unless authors *or users* delete the entries. #1276.
• Possible race between Activate and Update Algorithms: Possible race between Activate and Update Algorithms #1285.
• Consider a method to force immediate disk deletion even if there are live Cache/Response js objects: consider a method to force immediate disk deletion even if there are live Cache/Response js objects #1287.
• SharedWorker script interception after redirects: SharedWorker script interception after redirects #1289.
• Client.postMessage() throwing for unloaded client is problematic: Client.postMessage() throwing for unloaded client is problematic #1291.
• Confusion around new events after skipWaiting: Confusion around new events after skipWaiting #1295.
• Cache API: Cache-Control headers and Opaque Responses: Cache API: Cache-Control headers and Opaque Responses #1299.
• Should prefetch loads trigger FetchEvents?: should prefetch loads trigger FetchEvents? #1302.
• Spec says update() should resolve to a registration, but browsers do different things: spec says update() should resolve to a registration, but browsers do different things #1304.
• How can unregister()'s same-origin check ever fail?: how can unregister()'s same-origin check ever fail? #1305.
• Service-Worker-Allowed can be cross-origin to the script URL.: Service-Worker-Allowed can be cross-origin to the script URL. #1307.
• Merge with storage: Merge with storage #1230.
• Background Fetch review
  • Related issues: Keeping the service worker awake during a fetch. Does Background Fetch satisfy these requirements?
    • Error handling for aborted streams feeding a navigation request: error handling for aborted streams feeding a navigation request #1184.
    • How long can the service worker stay awake during an active fetch: How long can the service worker stay awake during an active fetch #1182.
• Covering use cases of foreign fetch?
• Dynamic import modules: Clarify dynamic-imported scripts are never installed #1356
• No way to beacon during activate: No good way to beacon during activate #1336

WPT status

TODO: Update this section.

Interesting feature requests

• Bypassing the service worker in particular cases
  • Proposal: Allow addEventListener/removeEventListener for 'fetch' to called at anytime: Proposal: Allow addEventListener/removeEventListener for 'fetch' to called at anytime #1195.
  • Consider mechanisms to bypass the service worker for things that we know won't be in it's cache: Consider mechanisms to bypass the service worker for things that we know won't be in it's cache #1026.
• Service workers in the clients API & adding to windows
  • Clients.matchAll() should exclude the current environment: Clients.matchAll() should exclude the current environment #1037.
  • Support returning ServiceWorker Client environments from Clients.matchAll(): Support returning ServiceWorker Client environments from Clients.matchAll() #1036.
  • Consider exposing self.clients on window and other worker globals: consider exposing self.clients on window and other worker globals #955.
• Recovering from fetch failures: Recovering from fetch failures #939.
• Enabling multiple Service Workers for a single scope: Enabling multiple Service Workers for a single scope #921.
• Consider providing navigation event: Consider providing navigation event #1028.
  • Service Worker Launch Event: https://wicg.github.io/sw-launch/
  • Single-window mode option manifest#597
  • A way to control which client (or type of client) receives a navigation: A way to control which client (or type of client) receives a navigation #758.
• Lifecycle for the web
  • User initiated 'uninstall' event: user initiated 'uninstall' event #998.
  • WICG proposal: https://github.com/WICG/web-lifecycle.
  • Back forward cache
    • Consider how Client API should behave with bfcache: consider how Client API should behave with bfcache #1038.
• Consider firing a "clientcontrolled" event on ServiceWorkerGlobalScope: consider firing a "clientcontrolled" event on ServiceWorkerGlobalScope #886.
• Allow caches to opt-in to granular cleanup: Allow caches to opt-in to granular cleanup #863.
• Preventing / delaying service worker updates
  • Preventing server-forced updates: Preventing server-forced updates #822.
  • Feature request: Provide a way to delay execution of a new service worker: Feature request: Provide a way to delay execution of a new service worker #1208.
  • Allow preventing the update process to finish: Allow preventing the update process to finish #761.
• Save initial files into cache storage instead of browser's cache: Save initial files into cache storage instead of browser's cache #820.
• registration.ready promise: registration.ready promise #770.
• Support updating multiple service workers coherently: support updating multiple service workers coherently #727.
• A way to immediately unregister a service worker: A way to immediately unregister a service worker #614.
• Consider exposing size for cache entries: consider exposing size for cache entries #587.
• Provide a one-line way to listen for a waiting Service Worker: Provide a one-line way to listen for a waiting Service Worker #1222.
• Provide a way to skipWaiting when the last tab refreshes: Provide a way to skipWaiting when the last tab refreshes #1238.
• Provide an easier way to listen for waiting/activated/redundant Service Workers: Provide an easier way to listen for waiting/activated/redundant Service Workers #1247.
• Service Worker handling of first page load subresources: Service Worker handling of first page load subresources #1282.
• Allow users to extend ExtendableEvent, anywhere: Allow users to extend ExtendableEvent, anywhere #1290.
• Formalizing a timeout API: Formalizing a timeout API #1292.
• Allow active worker to immediately evict itself: Allow active worker to immediately evict itself #1296.
• Give a fine grade to the Service Worker's lifetime: Give a fine grade to the Service Worker's lifetime #1297.

V1

Should have been done by this point.

• Issues: https://github.com/w3c/ServiceWorker/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Version+1%22.

[wanderview]

If possible I'd like to discuss a proposal for a new API to help sites measure the performance of their FetchEvent handlers. It spans both the WebPerf and ServiceWorker API surface. I'm going to be discussing it in WebPerf on Friday, but I'd also like to discuss with the ServiceWorker group on Thursday if possible.

The explainer for this proposal can be found here:

https://github.com/wanderview/fetchevent-worker-timing/blob/master/explainer.md

Thanks!

[jakearchibald]

@jatindersmann huge thank you for getting the agenda together. I realise I've been totally useless this time around.

If we get time, I'd like to discuss:

• cache.match generating partial responses #913.
• I'd like to get cross-implementation feelings about performance state & goals, and I promise not to say "static routes" (this is a lie).

And that's it, @jatindersmann already captured everything else 🎉

[jakearchibald]

Also: We didn't have a meet-up this year. Was that a bad thing?

[tomayac]

One thing that came up in the Devices and Sensors WG and that I would like to discuss is geofencing and how it relates to service workers. Abstracting from that, essentially we are looking for some sort of mechanism ("Alarms API") to wake up a service worker based on an event (which could be a geofence being crossed but should not be limited to that) to do some work. Here is the related issue: w3c/geolocation-sensor#22.

[jakearchibald]

A couple of folks today have mentioned the complexity of testing service workers (@yoavweiss, @rniwa). We could introduce something specific for testing mode (we did something similar for background fetch), but maybe we can do something that would benefit regular users too?

[jakearchibald]

@tomayac

we are looking for some sort of mechanism ("Alarms API") to wake up a service worker based on an event

Isn't this covered by https://w3c.github.io/ServiceWorker/#extensibility?

[tomayac]

Isn't this covered by https://w3c.github.io/ServiceWorker/#extensibility?

@jakearchibald This is exactly what I would want to discuss. Or if there needs to be another primitive.

[jakearchibald]

@tomayac could you write up an issue or DM me about this? I think I can answer this before Thursday, & it doesn't need to take up the time of the room. If it turns out it does need the room to discuss, at least we'll have the problem written up in a way that gets everyone caught up quickly.

[tomayac]

A chat with @jakearchibald indeed removed the need to discuss this. It's covered by https://w3c.github.io/ServiceWorker/#extensibility.

[wanderview]

Maybe we should discuss the cache API ordering issues:

#823 (comment)

[jakearchibald]

Action item: Now's the time to provide something like .ready for a specific registration.

.ready returns the same promise forevermore, which is confusing. Look at deprecating and doing something better.

[ewilligers]

I'd also like to discuss File Handling.

[jakearchibald]

Action: start using the "decided" tag again.

[jakearchibald]

F2F: Things linkedin would like this see:

• unregister({ force: true }) - unclaims pages.
• skipWaiting({ deadline: 0 }) - kill the current active service worker regardless of events after this time.
• worker.skipWaiting() - please.
• Adding a timeout on waitUntil proper

Will things break if we fire controllerchange when the controller becomes null.

skipWaiting({ deadline: 0 }) is higher priority than unreg, but only just.

Instead of skipWaiting({ deadline }), how about serviceWorker.terminate() / self.terminate(). Also useful for tests. Or unsafelyDispose()? @wanderview is worried that it's a footgun.

EDIT by falken: Merged in some of the minutes into here.

[jakearchibald]

AI for @jakearchibald create an issue for a rough static routes proposal.

[DeltaEvo]

Hello,

I was interested in Foreign Fetch, is something has been discussed to cover it's use cases?

Sorry to bother you and thanks for your attention 😄

[wanderview]

@DeltaEvo We did not end up discussing foreign fetch use cases at this meeting. Sorry.

[asakusuma]

@jakearchibald
FWIW, there's already a terminate() for web workers. Not sure if using the same name would be confusing or better. Probably confusing if we add service worker specific options.

It's unclear to me what exactly unregister({ force: true }) vs terminate() would mean. I believe the simplest MVP to accomplish what we (linkedin) want would be to add options to unregister() that allow immediately stopping any new events being sent to the service worker (even for already opened clients) and then terminating all associated workers (and their associated tasks) with some time guarantee. For instance:

// Immediately stop sending events to the service worker, all
// workers will be completely gone within 10 seconds.
navigator.serviceWorker.unregister({
  unclaim: true,
  terminateDeadline: 10000
});

I believe "unregister" is simpler, because it doesn't have to deal with transitioning events to another worker, which is needed if the active worker is terminated and there's a waiting/installed worker.

[mfalken]

@asakusuma It'd be better to discuss on the dedicated issues, #1292 in this case. Can you repost it there?

[asakusuma]

@mattto good call, though I'm not actually sure which issue to move to. #614 or #1296 might also fit

[mfalken]

@asakusuma Ah fair enough, we can continue here. As an implementor I feel I like the contract of unregister(force) or skipWaiting(timeout) over terminate(). Whether to declaim clients or evict the active worker is only indirectly related to whether the active worker is actually running. I can imagine some race conditions where we terminate the active worker but it gets woken up before activation can be triggered.

[asakusuma]

@mattto not sure I follow the theoretical race condition. How would the terminating worker get woken up if events are no longer being sent from the clients?

If we can table terminate for now, let's move the conversation to #1303

[arpit-gagneja]

@jakearchibald any updates on #1026?
I wish service worker API can provide us the ability to bypass the service worker for certain cases. I have experienced the performance regression on the page load time when there are too many network requests.