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