Serviceworker: Create F2F agenda - 25 October 2018

Created on 20 Apr 2018  路  23Comments  路  Source: w3c/ServiceWorker

Where

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

Minutes

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

WPT status

TODO: Update this section.

Interesting feature requests

V1

Should have been done by this point.

picture jatindersmann
👍2

Most helpful comment

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

picture tomayac on 23 Oct 2018
👍2

All 23 comments

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!

wanderview picture wanderview on 20 Oct 2018
👍1

@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 picture jakearchibald on 22 Oct 2018

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

jakearchibald picture jakearchibald on 23 Oct 2018

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: https://github.com/w3c/geolocation-sensor/issues/22.

tomayac picture tomayac on 23 Oct 2018

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 picture jakearchibald on 23 Oct 2018

@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?

jakearchibald picture jakearchibald on 23 Oct 2018
👍1

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.

tomayac picture tomayac on 23 Oct 2018

@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.

jakearchibald picture jakearchibald on 23 Oct 2018

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

tomayac picture tomayac on 23 Oct 2018
👍2

Maybe we should discuss the cache API ordering issues:

https://github.com/w3c/ServiceWorker/issues/823#issuecomment-417788337

wanderview picture wanderview on 25 Oct 2018

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.

jakearchibald picture jakearchibald on 25 Oct 2018

I'd also like to discuss File Handling.

ewilligers picture ewilligers on 25 Oct 2018

Action: start using the "decided" tag again.

jakearchibald picture jakearchibald on 25 Oct 2018

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 picture jakearchibald on 25 Oct 2018

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

jakearchibald picture jakearchibald on 25 Oct 2018
❤1

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 :smile:

DeltaEvo picture DeltaEvo on 26 Oct 2018

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

wanderview picture wanderview on 29 Oct 2018

@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.

asakusuma picture asakusuma on 31 Oct 2018

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

mfalken picture mfalken on 31 Oct 2018

@mattto good call, though I'm not actually sure which issue to move to. https://github.com/w3c/ServiceWorker/issues/614 or https://github.com/w3c/ServiceWorker/issues/1296 might also fit

asakusuma picture asakusuma on 31 Oct 2018

@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.

mfalken picture mfalken on 31 Oct 2018

@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 https://github.com/w3c/ServiceWorker/issues/1303

asakusuma picture asakusuma on 31 Oct 2018

@jakearchibald any updates on https://github.com/w3c/ServiceWorker/issues/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.

arpit-gagneja picture arpit-gagneja on 10 Nov 2018
Was this page helpful?
0 / 5 - 0 ratings

Related issues

cdumez picture cdumez  路  10Comments
jakearchibald picture jakearchibald  路  12Comments
mfalken picture mfalken  路  10Comments
liebrand picture liebrand  路  6Comments
jeffposnick picture jeffposnick  路  11Comments