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