06:31:21 RRSAgent has joined #serviceworker 06:31:21 logging to https://www.w3.org/2018/10/25-serviceworker-irc 06:31:34 q? 06:35:56 Zakim has joined #serviceworker 06:36:01 q? 06:43:23 shimazu has joined #serviceworker 06:53:34 beverloo has joined #serviceworker 06:58:03 n8s has joined #serviceworker 07:02:02 present+ Jungkee_Song 07:03:51 present+ Matt_Falkenhagen 07:04:31 present+ Marijn_Kruisselbrink 07:04:44 jmann has joined #serviceworker 07:04:44 xing has joined #serviceworker 07:04:52 youenn has joined #serviceworker 07:04:57 ericwilligers has joined #serviceworker 07:05:00 aliams has joined #serviceworker 07:05:16 present+ Ali_Alabbas 07:05:22 flaki has joined #serviceworker 07:05:27 present+ Peter_Beverloo 07:05:31 asa has joined #serviceworker 07:05:38 present+ Eric Willigers 07:05:52 present+ Makoto_Shimazu 07:05:59 present+ Flaki 07:06:36 JakeA: this is the first time we meet since there are implementations in all four browsers! 07:07:42 JakeA: Since there are now implementations, we will start with old stuff, then go on to the new stuff 07:08:40 jungkees: we can't really change anything about other specs so we should just file comments on those and talk about going CR 07:09:00 JakeA: anybody has any objections against going CR? 07:09:21 https://github.com/w3c/ServiceWorker/pull/1242 07:09:29 present+ JatinderMann 07:09:55 Agenda issue: https://github.com/w3c/ServiceWorker/issues/1303 07:10:16 aliams: we should also slot in and hear about LinkedIn's experiences with SW 07:11:28 jungkees: 3 PRs are already in, maybe 2 PRs left, we can gather additional comments during this meeting and polish the CR 07:11:53 falken: do we have to separate V1 tests from other tests? 07:12:00 jungkees: we need to address that 07:12:33 jungkees: currently we have tests only for the Nightly version, not for V1 07:13:10 JakeA: we're probably the first spec that has this problem... 07:13:19 wanderview has joined #serviceworker 07:13:23 present+ Andrew_Sutherland 07:13:33 s/probably the first spec/probably not the first spec/ 07:13:36 present+ Ben_Kelly 07:14:15 JakeA: is there any user agent specifically targeting V1? 07:14:24 kbx has joined #serviceworker 07:14:50 JakeA: aliams if do the work and separate off a V1 test suite, will that help? 07:15:00 aliams: it's more like a pragmatic thing 07:15:15 mgiuca has joined #serviceworker 07:15:55 ytausky: we mostly care about the features 07:16:03 s/ytausky/youenn 07:16:36 ???: are there minor feature changes expected after we go V1? 07:16:57 JakeA: mostly just small fixes 07:17:03 tomayac has joined #serviceworker 07:17:15 wanderview: we want to stay web compatible 07:17:54 https://github.com/w3c/ServiceWorker/blob/6653260801b38302401292898a74517d11f49e1c/docs/v1/cr_plan.md 07:17:54 jmann: we shouldn't worry too much about V1, it's something would be a nice to have 07:18:09 jmann: the spec has been stable for a while, we have conforming implementations... 07:18:49 jungkees: link to PR plan with a table of tests 07:19:10 jungkees: we could keep track of these to see where we are regarding V1 07:19:44 JakeA: that's it for V1 then? this year we're done in 90 minutes 07:19:57 JakeA: thank you for MS folks for taking care of the agenda! 07:20:08 JakeA: anybody feels something missing from the agenda? 07:20:32 wanderview: I think we had a discussion about cache storage & durations, should we add transactions etc 07:20:53 wanderview: I think we came to a conclusion, maybe we want to talk about it in the wider group? 07:21:09 wanderview: there are no ordering guarantees currently in Firefox or Chrome 07:21:30 JakeA: yeah we should definitely talk about it, and maybe spec it a bit better 07:22:12 q+ 07:22:45 wanderview: this might impact optimizations so we should at least talk about it 07:22:56 link to the cache API ordering issues: https://github.com/w3c/ServiceWorker/issues/823#issuecomment-417788337 07:23:21 Agenda issue: Multiple service worker instances 07:23:45 JakeA: #756, #1185. 07:23:46 https://github.com/w3c/ServiceWorker/issues/756 07:24:24 JakeA: the specification allows for one instance, some implementations allow for up to two concurrent instances 07:24:31 https://github.com/w3c/ServiceWorker/issues/1185 07:25:39 aliams: yes we had earlier a background service worker, now we reconcile if you have edge open the push notification will go to the foreground SW (but still get the benefit of having a background SW when edge is closed) 07:26:01 JakeA: safari looking at push? 07:27:11 I have made the request to generate https://www.w3.org/2018/10/25-serviceworker-minutes.html Yves 07:27:15 youenn: ... 07:28:24 JakeA: we also have this issue with two tabs, two processes and a service worker in a separate process 07:28:33 aliams: we have the SW in its own process 07:28:54 youenn: we have a SW per origin, we're trying to reduce the number of processes 07:29:43 wanderview: one could spin up a SW in a separate process, and just stop sending events to the old one whence that is up 07:30:11 JakeA: group stance sounds the same as before, we are all interested and experimentation might happen 07:30:49 falken: 07:31:28 aliams: in edge when the browser is not running, the background SW won't get fetch events so it's almost the same case 07:31:39 Agenda issue: Service worker resurrection 07:31:52 https://github.com/w3c/ServiceWorker/issues/1204 07:32:17 JakeA: developers are often surprised by this behavior 07:32:41 wanderview: we don't have test coverage 07:32:52 JakeA: we don't test the subscriptions... 07:32:54 s/ /suggest we update https://github.com/w3c/ServiceWorker/issues/756 with Edge's new behavior 07:33:16 n8s: it's almost impossible to test 07:33:20 JakeA: kill it? 07:34:09 JakeA: we have developer pressures 07:34:19 tomayac_ has joined #serviceworker 07:34:25 wanderview: we might need to rewrite a lot of our tests... 07:34:46 aliams: would you mind summarizing? 07:34:58 aliams: so we could make an informed decision 07:35:18 wanderview: if we're gonna vote it should be "we will do this in the next X quarters" 07:36:05 JakeA explains the usecases 07:37:07 JakeA: some of the usecases would probably be better exposed in the devtools, than buy into the confusion around resurrection behavior 07:37:43 n8s: you want to clean up after yourself, probably login/logout is the most oft-stated usecase 07:38:19 https://github.com/w3c/ServiceWorker/issues/1198 07:38:48 Agenda issue: ready promise weirdness 07:39:51 wanderview explains edge cases 07:39:55 https://github.com/w3c/ServiceWorker/issues/1278 07:39:59 n8s: this actually affects us 07:40:23 JakeA: should we add `ready` to the registration object? 07:40:31 JakeA: that might be clearer 07:40:40 n8s agrees 07:41:37 aliams: do we keep `ready` on serviceworker? 07:41:41 JakeA: yes 07:41:51 wanderview: it would be breaking change if we removed 07:42:56 wanderview: maybe we could make it a function to solve scope usecases? 07:43:34 JakeA: should we add an action item to get ready promise for a specific scope? 07:43:57 falken: should we just add a `getNewestReadyPromise()`? 07:44:06 JakeA: newest as in..? 07:44:48 falken: *explains* 07:45:30 falken: if I could do it again, I would just make `ready` a function. I would deprecate ready, and add a function. 07:45:41 wanderview: `betterReady`? :) 07:45:46 Chair: JakeA 07:46:00 present+ asuth 07:46:32 Meeting: Service Worker WG F2F 07:46:36 asuth: *raises concerns related to firefox's implementation regarding privacy and push* 07:46:55 Agenda: https://github.com/w3c/ServiceWorker/issues/1303 07:47:02 I have made the request to generate https://www.w3.org/2018/10/25-serviceworker-minutes.html Yves 07:47:36 present+ Yves 07:48:02 present+ Youenn 07:48:49 Agenda item: https://github.com/w3c/ServiceWorker/issues/1189 07:49:59 falken: looks like we have resolved this in the tests 07:50:08 wanderview: yes 07:50:42 falken: so we should update the spec, did we land the tests yet? 07:51:06 Agenda item: FetchEvent.navigationLoadType: #1167 07:51:20 falken: I think we have already fixed this in `fetch` 07:51:41 falken: this should be in the spec now 07:51:48 jungkees: yes 07:52:05 falken: should we close it? 07:52:10 jungkees: does Fetch have a related issue 07:52:19 falken: yes 07:52:32 JakeA: we will close this for now and double-check later 07:52:54 Agenda item: https://github.com/w3c/ServiceWorker/issues/1200 07:54:51 falken: I would not want to change this in our implementation 07:55:12 falken: this might not solve a real problem 07:55:28 JakeA: we should just turn this optimization a _may_ 07:55:45 n8s: I think further down in the issue that's what we agreed on 07:57:28 jungkees: what about other events? 07:58:04 marijn_k: implementers are still allowed to optimize for other events 07:58:49 soon_ has joined #serviceworker 07:58:59 JakeA: *break for 15 mins* 08:00:27 jillian_munson has joined #serviceworker 08:04:47 ScribeNick: Flaki 08:04:59 ScribeNick: flaki 08:05:21 Date: 25 Oct 2018 08:16:40 q? 08:21:52 soon has joined #serviceworker 08:21:58 soon has left #serviceworker 08:22:20 s_kr has joined #serviceworker 08:23:17 Topic: LinkedIn service worker experiments 08:23:35 mgiuca has joined #serviceworker 08:23:51 asa: *projecting* 08:23:53 ...we had site reliability engineers who were looking at various scenarios 08:24:56 ...we wanted to see what happens when we try to turn off a serviceworker with a standard noop killswitch 08:25:20 slightlyoff: did it also `claimAllClients`? 08:25:24 asa: yes 08:26:23 asa: we expect no repeat events 08:26:28 JakeA: repeat events? 08:27:05 JakeA: on next page load the old service worker will still fire an event, but the killswitch will take over, and no further events should be fired 08:27:38 asa: we were actually closer to 4 million users 08:27:42 dmurph has joined #serviceworker 08:27:55 ...we had a quite long tail, this was a little higher than we were expected 08:28:30 ...what we would like to see is some time guarantees that an update will take place in a certain amount of time 08:29:03 ...it would be good to avoid forced refresh so the user is minimally affected 08:29:48 asa: we have feature flags inside our service workers (static asset caching only turned on for employees) 08:31:03 jmann has joined #serviceworker 08:31:09 n8s: most of this we do in our code already 08:31:21 n8s: we check on all request for a killswitch header 08:32:15 n8s: a header like this (especially with the swapping out of the controller) would feel to be hard to get right 08:32:31 ...a lot of this feels like this is better handled in app code 08:32:39 shimazu has joined #serviceworker 08:32:51 slightlyoff: you want to "`disclaim`" a client? 08:33:17 n8s: it is also possible to wrap the fetch handler and just unregister it? 08:34:16 asa: code that relies on safeguards in previous workers are not ideal 08:34:31 JakeA: why do you think your old code was not working? 08:34:52 asa: one idea is that the service worker never relinquishes control 08:35:45 wanderview: also some browsers have intrinsics for firing updates when idle, especially on low-end devices that might not happen 08:36:28 asuth: do you have a breakdown of the breaking browsers? 08:36:42 asa: yes, it was pretty consistent across browsers 08:37:22 ...we had a prototype using `postMessage` between workers but it turned out to be an order of magnitude worse 08:37:37 slightlyoff: do you have an idea if your `postMessage` was received? 08:37:59 asa: *response to slightlyoff* 08:40:58 asa: we negotiate service worker versions via `postMessage`, and for blacklisted workers we call `skipWaiting` 08:41:54 see https://tools.ietf.org/html/rfc7234 08:42:14 JakeA: you could use ETAG-s and do this on the server side maybe? 08:42:59 JakeA: we have an issue which is essentially unclaim clients, would that be useful? 08:43:06 asa: maybe? 08:44:58 asa: I think we both at facebook and linkedin added timeouts to `waitUntil`, to ensure it does not keep on waiting forever 08:45:15 slightlyoff: maybe we should add that to `waitUntil` proper? 08:45:23 n8s: yeah that sounds useful 08:47:01 *discussion about user experience and shutdown deadlines in `skipWaiting`* 08:48:39 *discussion about adding timeouts for other promises like `fetch` and push notifications* 08:49:36 wanderview: it would be great to spec disclaiming clients further in the spec, which we currently don't have a way to do 08:50:56 JakeA: which features would you prioritize? 08:51:07 asa: resurrection? 08:51:16 JakeA: we're probably killing resurrection 08:51:22 n8s: skipWaiting timeot? 08:51:28 asa: *agrees* 08:52:03 JakeA: we have a long-standing issue of adding `skipWaiting` to the SW object 08:52:08 asa: that would be really nice 08:55:12 JakeA: so priority is `skipWaiting` deadline, then forced unregistration? 08:55:39 n8s: i see use in the second, but at least at Facebook `skipWaiting` would be more useful 08:57:38 Topic: idb performance vs context objects 08:58:03 asuth: is this about the "convenience storage spec"? (sync storage) 08:58:16 asuth: with limited storage size 08:58:50 ...we want to cap the storage size because of structured clone impl limitations 08:59:53 slightlyoff: we can just experiment with existing primitives 09:00:05 ...similar concerns were raised in the async cookie spec 09:00:22 JakeA: we should wait for convenience storage 09:00:37 ...if you want sync data in your service worker you need to ship it in your worker 09:00:39 n8s: yes 09:00:48 slightlyoff: that's the _only_ way to do it today 09:01:00 asuth: ...or with the urlparams hacks 09:01:07 this topic is https://github.com/w3c/ServiceWorker/issues/1331 09:02:37 flaki: is this addressing the issue of not being able to use global scope? 09:02:55 JakeA: that too, but cross-worker communication and other usecases 09:03:13 JakeA: convenience storage is tied to the origin 09:04:12 xing has joined #serviceworker 09:04:48 *discussion about service worker caching headers* 09:05:42 JakeA: we're listening to our users! n8s, you have anything? :) 09:06:11 n8s: sometimes we would love to avoid the overhead of a resource that we *know* we don't have cached 09:06:53 flaki: do you mitigate/work around this? 09:08:19 n8s: in the `fetch` handler when we hit a path we know it's not going to be cached we just respond right away with an empty response, to continue the native fetch, that seems to be a bit faster usually then going through the SW 09:08:39 JakeA: we should start talking to users about performance 09:09:00 falken: *talks about Chrome perf improvement work* 09:10:22 falken: we're finishing up a rearchitecture, we have it enabled for a few of our users 09:10:46 ...this might also improve service worker request performance 09:11:09 ...results are as of now inconclusive, but we have ideas how to further improve it 09:11:41 JakeA: navigation preload? 09:11:50 falken: it improved things 09:12:10 jmann: n8s do you use it at Facebook? 09:12:38 n8s: yes. it contributed some improvements, but no slam dunk. we don't really have data because we just use it everywhere now 09:13:39 jmann: *discussing network ???* 09:13:59 aliams: we mostly looked at minimizing service worker startup time 09:14:09 s/???/specific process/ 09:14:30 JakeA: how is that going at Apple? 09:14:37 youenn: we're busy implementing stuff :) 09:15:38 youenn: we won't have navigation preload, until we have optimized everything else 09:15:58 ...we are also interested in cache api optimizations, but it's not a large priority right now 09:16:24 ...iDB has started some work, and since they are related we are waiting to see how that progresses 09:18:19 slightlyoff: navigation preload and caching improvements are very different issues and they fix different usecases 09:18:31 n8s: *aggrees and clarifies* 09:19:50 youenn: we are trying to improve service worker adoption, that will help bump push in priority 09:20:02 asuth: in Mozilla our perf improvements are happening 09:20:14 ...we are working on turning Streams on 09:20:19 *cheers in the room* 09:21:46 asuth: the rest is cleanup and conformance fixes 09:22:28 Topic: Static roots and skipping requests going to SW 09:23:01 slightlyoff: we have a service worker on `google.com/search` 09:23:42 JakeA: but browsers support this in b/f cache? 09:24:19 slightlyoff: b/f cache is not enabled for this page for revenue reasons, but client-side we reuse the page data from the SW and it's a huge win 09:25:44 slightlyoff: proposes having unclaim some routes under sw control (and expose them to other sw that would be in shadow or no sw at all) 09:26:08 n8s: this has some overlaps with what we would want 09:26:18 slightlyoff: this is for toplevel navigation, not subresource though 09:26:28 aliams has joined #serviceworker 09:27:03 n8s: skipping is already exposed in the Fetch api 09:27:15 JakeA: that would require annotating all fetch requests 09:27:31 wanderview: one could also create a feature/policy configuration 09:27:51 ...but maybe still better to use a built-in primitive than creating a new high-level api 09:29:39 *discussion about the usefullness and shape of a possible high-level routing api* 09:30:50 this is how I would expose the "bypass service worker" primitive: https://github.com/w3c/ServiceWorker/issues/1195#issuecomment-340781059 09:33:39 jmann has joined #serviceworker 09:35:32 JakeA: I don't want to create an API that we will need to revisit every time we come up with a new feature/usecase 09:36:10 ...we need to design something that could cater to the usecases, and ship a limited featureset first 09:36:38 JakeA: so we're going to write up a design proposal? 09:37:04 wanderview: I want to add that there is a tradeoff between creating a new API in terms of focusing on what we have 09:37:39 ...if we could just expose an already existing primitive that would be less work and free up resources for other work 09:38:11 n8s: we could still explore how an API like this looked like without a requirement to ship anything 09:38:18 wanderview: *agrees* 09:38:54 slightlyoff: we should talk to TAG to figure out a way to sensibly do this extension 09:40:32 falken: I see three ways forward, we keep optimizing, come up with an API to skip service workers or a static route proposal. 09:40:41 ...we are bouncing between these ideas 09:40:49 ...we can of course do them concurrently 09:41:28 n8s has joined #serviceworker 09:41:32 wanderview: based on ES modules, where there is a lot of userspace module systems, a lot of opinions will come in 09:42:20 ...it seems we will have this with a lot of userspace routing systems and could be quite time consuming 09:43:09 slightlyoff: we need to make sure this is not a large land-grab for userspace libraries 09:43:34 JakeA: yes we just need to collect evidence to make sure we don't design ourselves in a corner 09:43:57 asuth: could large sites like Google or Facebook sketch out what kind of structure they would be looking at? 09:44:56 slightlyoff: *adds details on the requirements of Google's search case* 09:46:06 philipwalton has joined #serviceworker 09:48:06 JakeA: static routing is entirely limited to the features one could write in a `fetch` listener 09:48:45 kinuko has joined #serviceworker 09:48:55 n8s: do we want to move on? 09:49:31 wanderview: I have linked above a potential solution exposing `fetch`configuration 09:49:39 JakeA: I'm interested in speccing this 09:49:43 https://github.com/whatwg/fetch/issues/492 09:51:30 this was what I was referring to as my potential solution: https://github.com/w3c/ServiceWorker/issues/1195#issuecomment-340781059 09:51:36 *discussion mentioning "fetch worklets"* 09:52:07 slightlyoff: *clarifies the distinction between fetch worklets and service workers* 09:53:09 Topic: fetch keepalive 09:53:11 https://github.com/w3c/ServiceWorker/issues/1336 09:58:03 flaki: *Clarification:* keepalive ensures a fetch event will follow through (with pre-set timeouts kept in mind) even if the page (or service wokrer) is shut down 09:58:37 asa: usecase is tracking beacons inside the service worker (originating from the worker itself) 10:00:09 falken: question is how service workers will respect these 10:00:19 ...I want service workers to respect this 10:00:37 JakeA: maybe we just need more agressive timeouts in SW? 10:01:42 falken: it feels like respecting Fetch keepalive in browsers is what we want 10:01:45 *agreement* 10:02:17 falken: *will see into chrome implementation* 10:31:34 Zakim has left #serviceworker 11:08:46 n8s has joined #serviceworker 11:11:53 Topic: Launch Event 11:12:02 mgiuca has joined #serviceworker 11:12:16 Topic: https://github.com/WICG/sw-launch/ 11:14:16 n8s: I'm not sure I want to pay the latency cost of both firing a launch event and fetch event. 11:14:43 ... Could potentially delay preload. 11:15:40 https://wicg.github.io/sw-launch/explainer.html 11:19:52 ?: the `launch` event is not even fired once you already have the window from something like an app icon opened -- the OS will just focus your window 11:20:38 ...this is more for things like `target=blank` navigations 11:20:59 asuth: Firefox wouldn't want it to break the back button / history. 11:21:25 flaki: is this for something like when a site doesn't want multiple windows of it open? 11:21:36 n8s: yes 11:22:15 asuth: I could imagine a "searching google to open facebook" scenario when we might want to bring e.g. a pinned Facebook tab into view instead of opening a new window... 11:24:11 ?: PWA-s have a usecase for this 11:24:11 ...also for applications like "read it later" that do something in the background and just `preventDefault` 11:24:55 asa: is this the same thing that an app wants a single window? 11:25:04 ?: yes 11:25:10 s/?/mgiuca 11:25:46 wanderview: but Web APK's do this already, aren't they 11:25:52 ...? 11:26:24 mgiuca: yes, it enforces this behavior. partly that's where this request comes from. 11:28:53 aliams: *discussing the Windows store behavior for the Twitter PWA in cross-linking scenarios between apps* 11:29:06 AliA: Windows PWAs do link capturing, but only when coming from a non-browser app. 11:29:17 beverloo has joined #serviceworker 11:29:19 shimazu has joined #serviceworker 11:31:04 n8s: can this just be a declarative part of the manifest? 11:31:55 mgiuca: if further features arose would cause issues, it's easier to expose an event that could handle all (potential future) usecases 11:33:18 tomayac has joined #serviceworker 11:36:10 ?: Should be a hint, that is ultimately up to the usre agent. 11:37:08 ?: I'm not sure we want the performance overhead. Whereas a static link would be better. 11:37:12 s/link/hint 11:38:02 s/?/youenn 11:38:04 AliA: Could have a timeout where if you fail to respond in that time, we take a default action. 11:39:09 s/?: Should/flaki: Should 11:42:01 jmann: in windows the developer makes an initial intent/decision and the user can override it in the settings 11:42:20 ...this contributes to a more consistent experience 11:44:06 mgiuca: *explains the `mailto:` usecase using the `registerProtocolHandler` API* 11:45:19 mgiuca: if people are concerned about the performance aspect, we should make this an opt-in 11:45:49 wanderview: Could be some privacy concern if we are triggering code that can run and show no response to the user. 11:45:53 wanderview: *raising a privacy concern of not showing anything but running something in the background* 11:46:05 ... eg can use fetch to geolocate 11:46:25 ericwilligers: If they do nothing (e.g., no notification, no focus window), then we could force-open a tab. 11:47:13 asuth: spec-wise, who should worry about this? PWA's are not standardized, and this feels like a very UX-centric issue 11:47:33 mgiuca: would this more belong to the Manifest spec where most of PWA/UX features live? 11:47:37 asuth: maybe? 11:48:27 JakeA: If we went for a declarative hint option, it should be in the manifest (not SW). 11:48:33 Topic: File Handling 11:48:41 https://github.com/ewilligers/file-handling/blob/master/explainer.md 11:48:50 Speaking: ericwilligers 11:50:34 mgiuca: this includes write access 11:50:51 wanderview: isn't this like the Web Share API 11:51:04 mgiuca: Web Share is read only 11:51:17 ...this is more "pass by reference" than pass by value 11:52:17 JakeA: I'd love to see PWA's appear in the open-with dialog, that's what we are aiming at 11:52:20 falken: What would the user experience look like? 11:52:41 (many): You are in the operating system file browser, and you right-click, Open With -> opens in a browser. 11:52:46 (In an installed PWA) 11:52:53 s/(In/... (In 11:53:25 JakeA: whether the implied write access is safe to expose that might still need discussing 11:53:44 ericwilligers: couldn't this be just part of the launch event? 11:53:51 youenn: Can you process the file in the service worker? 11:54:03 youenn: maybe, but there are complications 11:54:39 s/youenn: maybe/youenn: maybe one could include this as part of the `launch` event/ 11:54:42 (flaki: I think ericwilligers and youenn should be swapped) 11:55:23 falken: why does this need to do to the service worker? 11:55:32 ...what would the service worker do? 11:56:00 mgiuca: this looks a lot like the launch event, but it has an important distinction 11:56:15 ...it has a special file object 11:56:42 youenn: Why not just add an extra attribute to the launch event? 11:58:08 jmann has joined #serviceworker 11:58:09 s/youenn: maybe/ytausky: maybe/ 11:58:55 aliams: would this be limited to installed PWAs? 11:58:58 jmann: yes 11:59:01 *agreement* 11:59:30 ericwilligers: I don't see how we would get the file into the app if we didn't have an event. (Set a global?) 12:00:54 mek: If you had a launch event, it would come in as a property on the event. Without a launch event, a new page would be created and then it would be given to the page (perhaps as a global variable, which is how Web Intents worked). 12:01:06 wanderview: Having an event to provide the file would be more flexible. 12:01:53 wanderview: Would the target site ever want to navigate away to another URL while keeping the file handle. 12:02:06 JakeA: This depends on discussion tomorrow of whether we can store file handles, e.g. in IndexedDB. 12:02:25 asuth: We were planning to rip out our mutable file handles in Firefox. 12:02:37 JakeA: Give it one more day :) (We are planning to discuss writable files in WebPlat tomorrow.) 12:03:09 q? 12:03:38 scribenick: mgiuca 12:03:39 Zakim has joined #serviceworker 12:04:07 https://www.youtube.com/watch?v=eLfgf2ZvFpo 12:04:29 aliams has joined #serviceworker 12:04:31 https://www.youtube.com/watch?v=eLfgf2ZvFpo 12:04:54 Topic: Background fetch. 12:05:07 JakeA is talking through the above video link. 12:05:22 JakeA: Podcast app. Tried to download a file but offline. 12:05:31 ... Now the whole browser is ejected from memory. 12:05:41 ... All the downloads are gone. 12:06:03 ... Background fetch is aiming to solve this. Hit download button, get a notification in the system tray. 12:06:36 ... Can kill the browser process. Notification is still there, still downloading. App is able to retrieve the state about this happening, and the background service will resume when the app is restored or connectivity is restored. 12:06:51 kinuko has joined #serviceworker 12:07:13 beverloo: If you use facebook to upload a photo, you need to keep website in foreground. 12:07:18 https://wicg.github.io/background-fetch/ 12:07:19 ... This also applies to uploading, not just fetching. 12:07:31 q? 12:07:52 n8s: What about metered connections? 12:08:01 s/n8s/flaki 12:08:17 JakeA: No permission to start a download. But the site is able to start a download in the "paused" state. 12:08:56 I have made the request to generate https://www.w3.org/2018/10/25-serviceworker-minutes.html Yves 12:09:05 flaki: What if the wifi cuts out, and the phone starts using mobile data. Can the website know this and behave responsibly with the user's data? 12:09:31 slightlyoff: We're working on this but in some cases, we don't know (the browser) because the last hop is WiFi but the connection itself is metered. 12:10:10 flaki: Windows exposes a per-connection setting so the user can tell the OS whether it's metered. Do we expose that to the site? 12:10:21 JakeA: Spec allows the site to pause/unpause at will. So the site can respect the user's wishes. 12:10:34 beverloo: We would need to use the network information API. 12:10:42 ... Chrome has a lot of heuristics to decide. 12:11:00 flaki: Do we expose the network switches. 12:11:08 aliams: https://wicg.github.io/background-fetch/#extensions-to-service-worker-registration 12:11:44 slightlyoff: When you don't have a SW running, this is the solution. It's a third-party service outside of the SW (it's more declarative). But you don't have a moment during this where the SW is potentially running. 12:12:13 ... SW, document and runtime might be completely gone. We need to set up a declarative thing that's handed over to the OS. 12:13:12 mgiuca_ has joined #serviceworker 12:13:20 youenn: (Apple): We like this. 12:13:37 scribeNick: mgiuca_ 12:13:40 flaki: OS will stop download and say "we paused this because you switched to metered connection, do you want to resume" (notify the user) 12:14:17 JakeA: dbaron concerned that this creates a notification for free. 12:14:36 ... Gives you a click event that goes to the SW. 12:14:44 ... Spec gives provision for an upfront permission prompt. 12:14:52 ... I would discourage it in favour of a paused download. 12:16:18 mgiuca: Could you tell the OS whether to download on metered connection? 12:16:50 JakeA: That should be solely up to the OS. No need to give the site control over that. 12:17:16 mgiuca: So all this discussion about giving the website info about whether it's a metered connection. Seems irrelevant since it's not the site's responsibility. 12:17:19 JakeA: Correct. 12:18:04 wanderview: Users may not be aware that a download has started. 12:18:04 beverloo: In Chrome for Android we're experimenting with ways of telling the user a download has started. 12:18:21 jmann: I like this one. 12:19:30 JakeA: This came up in TAG: when you do fetch, you give it a sequence of URLs, not just one. This lets you represent multiple fetches in a single entity for the user. e.g. a game with many assets; a movie split into chunks. The user should just see it as a single entity. 12:19:37 ... TAG was not super happy with this. 12:19:54 wanderview: Does it imply the browser should do something intelligent with this list (like doing them in parallel, etc). 12:20:06 JakeA: Mostly just to tell the user up front how big it is, and show a progress bar. 12:20:32 JakeA: If it overshoots (goes beyond the states amount) we will cancel it. 12:20:45 ... Developers should be conservative with the file size. 12:21:03 (You provide the expected file size as part of this API.) 12:22:44 (Discussion about whether the file size is given in compressed or uncompressed.) 12:23:18 mgiuca: Concern that we report a size much bigger than the actual amount of bytes we use on the network. 12:24:20 JakeA: Opposite problem: we often report "You've downloaded X / Y" where X is size on disk, and Y is compressed size. So we want Y to be the uncompressed size. 12:25:11 flaki: How do we deal with the multiple files. 12:25:26 JakeA: Sequence of icons and title. 12:25:44 mgiuca: What does multiple icons mean? 12:25:59 JakeA: Just different versions/sizes of the same logical image. UA will pick the most appropriate. 12:26:37 beverloo: Chrome is going to origin trial in Chrome 71 (the next upcoming version). But this doesn't include uploads. 12:27:05 [Note: Chrome 71 should be out early December 2018] 12:27:50 falken: Background fetch record includes the response. Does that mean the page can monitor the contents right away. 12:27:58 beverloo: Yes, so you can stream video while it's still going. 12:28:37 JakeA: Once you get the success event to the SW saying the whole thing is downloaded, it's your responsibility to store them somewhere more permanent e.g., the cache storage. After that, they get garbage collected from background fetch storage. 12:29:09 ... UA needs to be smart enough to not double-quota during this download. 12:29:33 ... Early versions of this proposal would directly download into the cache. Now we don't do that. 12:29:47 ... But we might want to provide a way to transfer into the cache without having to do a big copy operation. 12:30:15 wanderview: I don't think we should lie about how much disk space we're using. We should just minimize the amount of time we incur that cost. 12:30:32 (Discussion is around the fact that we would temporarily need 2x storage while we copy from the background fetch storage to the cache storage.) 12:31:27 JakeA: Some of this should be moved back into HTML because it's general to normal downloads. 12:31:43 ?: Customers? 12:31:56 beverloo: We will have a number of sites using it soon. 12:31:58 s/?/aliams 12:32:41 ? (LinkedIn): We would want to use this for uploads. 12:33:12 s/? (LinkedIn)/asa 12:33:21 beverloo: shakaplayer is getting support for BGS. 12:33:30 n8s: Facebook uses this so we would auto get this. 12:33:32 End of discussion. 12:54:43 https://github.com/w3c/ServiceWorker/issues/913 12:56:50 jmann has joined #serviceworker 12:57:32 scribeNick: falken 12:57:38 TOPIC: https://github.com/w3c/ServiceWorker/issues/913 12:57:56 JakeA: fixed the spec regarding range requests earlier this year 12:58:02 ... it's reasonably ok in chrome 12:58:18 ... returning 200 response for a partial request is working in chrome 12:58:19 ... not safari 12:58:31 ... proposal is for cache.match to return range responses 12:58:34 shimazu_ has joined #serviceworker 12:58:42 Yves: limiting yourself to a single range 12:58:54 JakeA: yes... never seen a browser do multiple ranges 12:59:20 Yves: can return 200 if given multiple range requests 12:59:47 JakeA: we've seen users polyfill this by generating range respones on the fly 12:59:54 ... bad impls are using array buffer, using up memory 13:00:01 ... i'm going to spec this 13:00:08 ... and we can investigate whether this will be a breaking change 13:00:27 ... sad cases is if the people polyfilling this aren't checking whether it's a 206 from cache 13:00:55 wanderview: there's some impl complexity... 13:01:09 ... if the impl does compression on disk 13:01:14 ... picking out a range from that is hard 13:01:29 ... firefox uses wire transfer encoding 13:01:37 ... cache storage uses snappy compression algo 13:01:43 ... it's certainly doable 13:01:58 ... provide metadata about checkpoints in the file, minor seeking, 13:02:02 ... not a blocker but not trivial 13:02:05 mek: overhead 13:02:15 Yves: can do this only for files that you won't compress 13:02:22 wanderview: firefox compresses everything 13:03:02 ... decision made because snappy is fast... there would be code complexity to detect the type since you can't trust the content-type 13:03:42 falken: can spec say browser may return 200 or 206 13:04:06 wanderview: there will be time to impl anyway so reality will be sites can't assume one or the other 13:04:15 JakeA: http spec you can do 200 or 206 13:04:22 ... 416... 13:04:29 Yves: if completely out of range... 13:04:40 ... otherwise browser can try to give what the user may want 13:04:51 ... 200 means "i'm not supporting that range request" 13:05:05 youenn: I saw the bug about Safari and 200 for partial requests 13:05:16 ... we would like to fix it 13:05:21 flaki: is this v1? 13:05:40 Yves: don't touch v1 13:05:43 JakeA: not touching v1 13:06:03 ... thinking about cache storage goes into its own spec 13:06:14 ... possibility that generating the range may become a MAY 13:06:26 ... developers are going to have to check anyway 13:06:45 [summarizing what we discussed earlier as people came into the room] 13:06:57 JakeA: can we say apple supports? 13:07:14 s/supports?/supports background fetch/ 13:07:19 youenn: will check internally 13:07:28 [started talking about support for bg fetch] 13:07:46 JakeA: decision: will spec and look into what sites are doing 13:08:28 TOPIC: FetchEvent Worker Timing API 13:08:40 shimazu has joined #serviceworker 13:08:59 wanderview: i've been working with sites understanding perf with sw enabled 13:09:16 ... for common cases of passthru fetch or directly to cache, those use cases are easily understood 13:09:22 ... but complex cases like sites with analytics etc 13:09:30 ... there's no much visibility into what's going on in their sw 13:09:39 ... sw is disconnected from the page 13:09:44 ... postMessage is clumsy 13:10:19 https://github.com/wanderview/fetchevent-worker-timing/blob/master/explainer.md 13:10:36 wanderview: [running through example from explainer] 13:10:52 ... fetch event is doing dynamic lookup from indexdb, not statically known 13:11:00 ... currently they can get workerStart to requestStart 13:11:06 ... tells you how long it took for the worker to start 13:11:12 ... but after that all they get is responseStart 13:11:24 ... don't know what happened between requestStart and responseStart 13:11:26 beverloo has joined #serviceworker 13:11:31 ... proposal is to expose user timing API 13:11:47 ... expose it in the fetchevent: performance.mark() and .measure() 13:11:56 ... so these are tied to the resource the fetchevent is for 13:12:08 ... in the end all those entries will show up in worker timing back in the main page 13:12:19 ... modelled after Server Timing API 13:12:33 ... on the SW you can add any entries you want 13:12:38 ... on the main page you can get them pack out 13:12:42 ... they are tied to that resource load 13:12:48 s/pack out/back out/ 13:13:05 [..any questions? no questions...] 13:13:14 wanderview: let's walk through key scenarios and design decisions 13:13:20 ... measuring navigations... 13:13:26 ... currently resultingClientId is not impl in any browser 13:13:33 ... this makes it impossible to collect metrics and use postMessage 13:13:50 ... performance navigation timing extends performance resource timing 13:13:54 ... so my proposal would just work 13:14:14 ... another situation are subresource loads that are duplicate in their url 13:14:24 ... consider a REST API... 13:14:31 ... wouldn't be able to map the url to the specific resource 13:15:07 ... my proposal would fi that 13:15:11 s/fi that/fix that/ 13:15:25 ... some sites use readablestreambody 13:15:42 ... filling the body of the response is coming after respondWith resolved... 13:15:51 ... want to support measuring these things also 13:16:15 ... proposal: as long as there's an outstanding waitUntil promise, you can still call this performance API 13:16:29 JakeA: you can get these performance marks after the response completed from the page's pov? 13:16:50 wanderview: yes... consider progressive caching... it's a use case that sites have asked to measure 13:16:56 ... talked this to perf wg 13:17:05 ... will talk about it tomorrow at perf wg 13:17:15 ... people seem ok with it 13:17:35 wanderview: today's performance observer api exists 13:17:49 ... it lets you observe when an entry is created 13:18:06 ... proposal: we don't fire the observer notification until the waitUntil is done 13:18:24 ... performance apis have to deal with cross origin timing attacks... timing-allow-considerations 13:18:42 ... don't think it applies here... because no additional information is exposed here 13:18:50 kinuko: navigations and redirects 13:18:54 wanderview: issue open about that... 13:18:57 ... couldn't add it to the document 13:19:13 ... i think whenever you would change a sw scope you would have to throw away any entries that have been built up 13:19:21 ... start conservative: on redirect all entries go away 13:19:27 mek: there are redirects anyway... 13:19:35 n8s: this is already polyfillable 13:19:45 ... i like the proposal because it mostly matches what we already do 13:20:01 youenn: can we point out which points are not polyfillable 13:20:09 ... so that we get more certainty on these points 13:20:14 wanderview: i think it's navigations 13:20:19 ... and resources that have the same url 13:20:38 n8s: for navigations, we assign a random id in the response 13:20:49 ... and post a message back to the sw to say associate me to this event 13:20:59 ... we keep track of which client did what request 13:21:15 ... if client is doing the same request for same url you kind of have to assume the order is correct 13:21:20 kbx has joined #serviceworker 13:21:32 wanderview: i believe the navigation mechanism you are using would be more difficult if you're not generating html in the sw 13:21:35 n8s: true 13:21:42 asa: [missed this] 13:22:00 wanderview: i think these things are pollyfibale but it's additional work 13:22:16 n8s: also we do this back-and-forth of ids with postMEssage, adds overhead 13:22:21 ... def better to do all this in one place 13:23:00 wanderview: i was initially worried that site could put a lot of data in the performance.mark 13:23:32 ... but perf wg people were saying they want to support putting objects in performance timing api 13:23:44 ... so i proposal we don't put limits here 13:23:56 n8s: what if you don't respond to the event, but want to mark that the sw saw it 13:24:00 wanderview: can still use waitUntil 13:24:33 n8s: if you do it sync without calling waitUntil, then you can send that back... 13:24:35 ... this all sounds good 13:24:42 jmann: i did the timing spec, this all sounds logical 13:25:22 JakeA: sounds like support in the room 13:25:34 asa: nice if there's a way to measure if the activate step is blocking other fetch requests 13:26:23 ... can measure how long the activate step is today, but can't know if it was blocking 13:26:36 n8s: youl'l see when the navigation start was and see when the workerstart was 13:28:06 [discussion of how to measure this today] 13:28:37 wanderview: let's open an issue 13:28:42 asa: will try it out and open an issue 13:28:58 [looking for next topic] 13:29:40 TOPIC: dynamic import modules 13:29:42 https://github.com/w3c/ServiceWorker/issues/1356 13:32:37 [explaining the issue] 13:32:43 flaki: why do people use dynamic imports 13:33:07 JakeA: is someone likely to have a large chunk of code they don't always want to execute at the start of the worker 13:33:34 ... example: say you've got a 10 MB script that you only need in 1/1000 startups... 13:33:44 flaki: sounds like webasm script inside your sw... 13:33:52 JakeA: can't dynamically import wasm yet 13:34:23 n8s: seems similar to fetch 13:34:25 JakeA: few options 13:34:42 ... if dynamic import is called it could go to the sw's fetch event 13:34:50 ... it could go to network or it could go to script cache 13:35:03 ... if it isn't in the script cache should it reject 13:35:39 asuth: seems like a footgun 13:35:46 ... should have the same semantics as static imports 13:35:49 ... or just throw all the time 13:36:00 wanderview: is it reasonable for them to have a static import for that thing then later use a dynamic import later 13:36:14 Mek: if static it's already imported 13:36:22 JakeA: could do something about importing classes 13:36:29 flaki: dynamic imports are a function that returns some value 13:37:48 falken: are other browsers implementing module service workers 13:37:50 [all no] 13:37:56 ["will get to it"] 13:38:08 falken: chrome can just punt on it and reject dynamic imports for now 13:38:15 wanderview: feature policy approach? 13:39:20 flaki: using modules and imports has this feel to me like you want to use all kinds of modules... 13:39:28 ... maybe want to import this and that... 13:40:01 JakeA: matching import scripts is compelling... 13:40:12 ... but for now throwing on dynamic imports sounds ok for now 13:41:01 wanderview: is storing module imports speced? 13:41:12 jungkees: no 13:41:25 asuth: package name map thing will be a problem? 13:42:16 [upcoming work] 13:42:39 TOPIC: https://github.com/w3c/ServiceWorker/issues/863 13:42:48 Allow caches to opt-in to granular cleanup 13:43:00 JakeA: I see a lot of sw examples in the wild that are adding everything to the cache 13:43:19 ... they will hit quota limit eventually 13:43:24 ... do we see libraries that do this? 13:43:43 slightlyoff: workbox has a side-bookeeping system in indexdb for implementing an lru for sw assets 13:44:01 ... don't know of many other impls other than workbox 13:44:07 ... what is everyone doing for storage mgt 13:44:14 n8s: we don't put a lot in our cache right now 13:44:23 ... just cache things in the install event 13:45:24 tomayac: ... 13:46:02 wanderview: fixed timestamps... 13:46:16 ... last-accessed might not be enough for what people are doing 13:46:24 n8s: concept of expiring stuff 13:46:31 ... if x day old, we unregister stuff 13:46:37 ... and check if we're not expired 13:46:56 wanderview: would timestamps match 13:47:05 tomayac: we can check what metadata workbox stores 13:47:11 ... they have the most industry experience of what everyone is doing 13:47:15 ... they allow different strategies 13:47:17 ... max 10 items 13:47:19 ... lru 13:47:26 ... they made it in a way that you can plugin your own strategy 13:47:41 ... this could guide how we design something natively 13:47:51 asa: if we can take cleanup off the activate step it'd be helpful 13:47:59 ... we're removing the whole cache in activate 13:48:06 ... but it'd be nice if we can tie a cache to a worker version 13:48:19 slightlyoff: we spent half a year talking about that idea 13:48:45 ... idea to let incoming worker claim the existing storage 13:48:53 ... for web plat consistency's sake didn't do that 13:49:17 asa: we would like to copy data between the worker versions as an optimizaiton, not doing it yet 13:49:34 ... would be nice if it didn't have to block the activate step 13:49:41 ... don't want cleanup to block 13:49:57 ... we deploy 2 times a day, so cache hit isn't that great anyway 13:50:26 n8s: do you use waitUntil? don't need to do it 13:50:40 ... write code in such a way that you cleanup wherever old stuff exists 13:50:50 wanderview: in theory the thread can be destroyed 13:51:22 slightlyoff: seems like common issue between indexeddb and sw cache 13:51:35 Workbox metadata in IDB: https://photos.app.goo.gl/88a4pQLhrjLtj35n8 13:51:36 ... want to build an index and do triming of your own outside of the critical path 13:51:45 ... imagine index worklet 13:52:03 n8s: respondWith in fetch then waitUntil for cleanup work? not ideal though 13:52:20 JakeA: make caches go away when the sw goes away... 13:52:27 ... puts onus on old sw to do the right thing 13:52:43 ... shorthand method like caches.something... pass it an array of caches and it deletes everything else 13:53:08 ... but if multiple sw in the same origin.... would need some path prefix naming 13:53:12 ... would get complicated 13:53:26 n8s: can come up with a heuristic 13:53:32 JakeA: three lines of readable code 13:53:37 asuth: how's the suborigins spec? 13:53:51 beverloo: code has been removed 13:54:19 wanderview: another proposal: anne's storage spec v2 with boxes 13:54:23 ... strategies for boxes 13:55:01 asuth: we don't have clear ownership model 13:55:09 ... browser nukes entire origin 13:55:22 ... manifest with list of caches would have a clear ownership model 13:55:33 slightlyoff: with regards to shared array buffer issue in gecko 13:55:43 ... i want an isolateMe or name storage partition 13:55:55 ... to run a doc inside separate isolated world 13:56:23 asuth: our session storage will be backed by local storage 13:56:28 ... that idea seems sane to me 13:56:40 slightlyoff: doesn't really help this question about pruning in single app 13:56:44 ... helps separate apps out 13:56:48 ... maybe these are two separate concerns 13:56:55 ... what do folks think of metadata extension on cache storage 13:57:03 asuth: structured clone metadata or typed meteadata? 13:57:11 JakeA: we'd define what that data is and when to set it 13:57:56 wanderview: know of sites that use at least one other piece of metadata . e.g., need indexeddb for each row in my cache storage. 13:58:25 asuth: indexdb has cleverness around blobs. ref counted. 13:59:10 JakeA: how are we feeling 13:59:30 wanderview: seems interesting but dont know how to safely write it back without stepping on yourself. multiple fetch events cause multiple accessing the same thing 13:59:41 JakeA: are we allowing devs to store arbitrary data or we record last access? 13:59:50 Mek: i think we said that's not enough... 13:59:55 wanderview: has to be arbitrary data 14:00:14 ... if we don't do that people still need more fields still need indexdb 14:00:35 asuth: we'd want to spec the sizing of structured clone data 14:00:46 JakeA: if idb were fast, any problems? 14:00:53 [still would be more convenient] 14:01:08 slightlyoff: coordination issue 14:01:47 asa: we only need cache time, expiration info 14:01:54 ... not complicated for us 14:02:15 asuth: i propose we put responses in indexdb 14:02:25 ... sounds like chromes cache api doesn't do vary correctly 14:02:35 wanderview: we want to fix that 14:02:48 ... transerrable streams is coming 14:03:06 ... path to getting things into indexdb 14:03:18 tomayac: if we put very simple metadata... 14:03:22 ... last access in cache entry 14:03:29 ... people could still do the advanced things with parallel struct in indexdb 14:03:50 ... most people just need simple timestamp 14:03:55 ... and can refresh the timestamp 14:04:04 ... timestamp represents last access 14:04:30 Yves: dpeneds on if you want to evict. 14:05:30 JakeA: if i call cache.matchAll, are all entries most recently used? 14:05:37 tomayac: yep 14:05:48 asuth: cache query options 14:05:51 ... update-the-timestamp 14:06:05 asuth: still have that problem that cache.keys can oom 14:06:40 ... ?? site that was storing everything in cache, cache.keys crashed chromium 14:06:52 JakeA: thinking of async iteration... 14:06:57 ... this is a really hard problem 14:07:06 ... dont want to solve just for workbox... 14:07:14 ... arbitrary object case is difficult if you have more than one library 14:07:23 ... easier to solve colocation update issue by allowing requests/responses in idb 14:07:33 tomayac: if there's just one place you have to keeep track of things that a lot better 14:07:44 slightlyoff: are we making responses transerable implictly? 14:07:50 ... define structured clone for response objects 14:08:08 wanderview: transerrence + structure clone 14:08:13 JakeA: structured clone waits for the whole body 14:08:16 Mek: it tees the body 14:08:36 JakeA: if you put response in cache it's read 14:08:43 wanderview: worried about implicit clones from perf standpoint 14:09:06 JakeA: to be successful, indexeddb would have to read all the body in a way that can be serielizated 14:09:09 ... you would never transfer to idb 14:09:27 wanderview: stream can't be structured clone. can be transferred via postmessage 14:09:31 JakeA: we'd have both 14:09:45 ... postMessage a resp without transferring, would read in the body. effectively structured clone 14:09:50 Mek: tee the body 14:10:23 wanderview: transferrable streams effectively get consumed in your current context 14:10:29 JakeA: maybe want both models 14:10:33 ... transfer and clone 14:10:50 wanderview: perf concern 14:11:01 asuth: chrome cache api. does it store ?? 14:11:09 ... firefox is moving to implement that 14:11:19 ... if you clone the resp can we still magically tie all the wasm transfer stuff together 14:11:52 ... do you need to do crazy optimization under the hood 14:12:07 wanderview: in chrome it's all tied to a url [missed this] 14:12:15 ... in firefox there's an object carried around that can't be cloned 14:12:18 ... diff arch 14:12:24 asuth: does url have magic equivalence 14:12:34 wanderview: internally it stores the cache name 14:12:45 ... response timestamp has to match to know it's the correct response 14:13:28 wanderview: the one before workbox had this problem 14:13:49 JakeA: conclusion: it's hard 14:14:00 ... dig into what it takes to put req/resp into indexeddb 14:14:36 TOPIC: testing of service workers 14:14:51 JakeA: heard from rniwa that sw are difficult to test 14:15:01 youenn: don't know precisely what that referred to 14:15:12 ... difficult to measure sw usage 14:15:23 ... want to ensure cold start vs non-cold start 14:15:37 ... we have internals API like terminateServiceWorker() 14:15:46 ... that could be shared in WPT 14:15:50 ... talked with WPT team 14:16:09 ... would need to define what this API does. spec it. 14:16:13 ... then can write tests using it 14:16:23 ... maybe done in a wiki or a spec 14:16:31 ... related to that is webdriver 14:16:37 ... does it make sense for a website to measure sw performance 14:16:50 ... webdriver to ensure sw's are terminated 14:16:58 beverloo: WPT is based on webdriver anyway? 14:17:06 ... similar issue with push notifications, bg sync 14:17:13 ... depend on external input, effectively untestable 14:17:18 youenn: payment request is like that 14:17:26 ... in webkit continuous integration testing we're using a mock 14:17:32 ... would be cool to take the tests 14:17:49 JakeA: you can add webdriver endpoints in specs 14:17:52 ... got one for background fetch 14:18:15 youenn: usually we impl a feature and and later impl webdriver support 14:18:36 ... we could do that 14:19:02 beverloo: conceptually if we want to test it, it should be something dev exposed and devs might test it 14:19:44 JakeA: regarding termination stuff... consider the api we pitched earlier of skipWaiting with the deadline... maybe we should put that back 14:20:04 ... another thing... 14:20:12 ... when dealing with workers... problem of communication with postMessage 14:20:23 ... with module workers do we have opportunity to do something better 14:20:26 kbx has joined #serviceworker 14:20:51 youenn: polyfillable... 14:20:56 JakeA: comlink 14:21:04 ... functions are a good start 14:21:29 ... export functions from a module worker and be able to access those on the other end 14:21:33 ... serielization is structured clone 14:21:44 ... suppose in a worker you export function double() 14:21:57 ... then in the window side, you can do await worker.exportedMethods; 14:22:03 aliams has joined #serviceworker 14:22:05 ... gives you moduleProxyThing that has .double() 14:22:20 ... worker runs, structure clones the response, resolves in the page 14:22:24 ... replacement for postMessage 14:22:31 ... is it worth trying to do somthing better 14:22:42 ... can do this as a library... so maybe not worth doing 14:22:49 asa: sounds nice, but opportunity cost 14:23:01 JakeA: not for this wg 14:23:07 ... domenic has some ideas 14:23:20 n8s: postMessage is annoying because it's slow, not because of the api 14:23:28 JakeA: would have the same perf characteristics 14:23:52 wanderview: if something terminates the worker you can reject this promise thing 14:24:01 youenn: in postMessage you have to keep the order 14:24:08 ... we do special IPC just to preserve the order 14:24:16 JakeA: maybe notion of order per function 14:24:25 youenn: maybe simpler to implement and optimize without order 14:24:38 beverloo: would be good to discuss this about module workers 14:25:43 TOPIC: Confusion around new events after skipWaiting 14:25:52 https://github.com/w3c/ServiceWorker/issues/1295 14:26:26 falken: spec intent is to use the active worker 14:26:35 n8s: current behavior is good 14:26:46 ... can kind of emulate the other direction if that's what you really needed 14:28:09 asa: language about queuing on window's run loop 14:28:27 ... is it possible instead of queing task on sw, you can go straight to network 14:28:51 n8s: if page is built around having a sw there... 14:29:12 ... option on skipWaiting to temporarily unclaim during update 14:29:18 asa: maybe superseded if timeout or way to terminate 14:30:42 n8s: terminate also sounds good 14:31:08 asa: will close the ticket 14:32:00 falken: in some cases a request will be dropped. we do that today too with the lame duck timeout 14:32:14 n8s: would only do this when somethings wrong and really want to evict the worker 14:32:31 wanderview: would we allow this everywhere? 14:32:38 ... only for redundant workers? 14:33:12 ... can be a footgun 14:33:33 Zakim has left #serviceworker 14:33:52 n8s: self.breakServiceWorker() 14:33:58 slightlyoff: unsafelyDispose() 14:34:08 asuth: have you ever had UAF bugs with workers 14:34:25 wanderview: i think we should explore this a little more 14:34:42 TOPIC: meeting cadence 14:34:48 JakeA: we didn't have a meeting this year until TPAC 14:34:57 ... what about next time? 14:35:22 ... options: meet at next tpac. calls? meet before next tpac? 14:35:26 kbx_ has joined #serviceworker 14:35:48 ... we had a call about multiple service workers once 14:36:02 jmann: we'll at least have one meeting a year from now 14:36:18 ... if a need arises we can do a call... reach out to chairs 14:36:21 ... async github has been good 14:37:37 youenn: was busy with impl. didn't particularly miss having a meeting 14:39:33 Brasserie De l'Est 14:40:11 https://www.brasseries-bocuse.com 14:42:22 n8s has joined #serviceworker 14:45:30 Drinks will be in Marriott Hotel Bar 14:53:00 n8s has joined #serviceworker 14:54:45 Are people at Mariott Hotel Bar already? 14:55:39 falken: I think Andrew may be 14:55:47 He's staying there 14:55:55 I'm heading over there shortly 14:57:20 tomayac has joined #serviceworker 15:13:18 i'll head over 16:00:32 n8s has joined #serviceworker