SV_MEETING_TITLE -- 08 Nov 2017

<slightlyoff> scribenick: slightlyoff

https://github.com/w3c/ServiceWorker/issues/1185

jake: there's conversation about this, safari might be using a similar patterns

bradee-oh: we're looking at it

(potentially)

JakeA_: if the notification is different from the fetch one, that's a compat issue for FB, right n8s_?

n8s_: we need notification click to be there so that we can konw if the page opened

n8s_: we rely on knowing that when we get a click on a notification, we need to know that the page opened (via global state)

bradee-oh: interesting

n8s_: it seems natural to know this

jmann: can you share motivation for that model?

bradee-oh: we havent' committed to a model, still exploring
... several reasons, they all tie back to battery life, CPU usage, etc. on iOS
... nitty-gritty details, largely Apple-specific
... iOS has evolved to ensure that expensive things are rare. We want to keep expensive things rare

JakeA_: multiple instances for fetch?

bradee-oh: still consdiering. Still on the table?

JakeA_: we'd like data. Would look at exposing service workers to the clients API.

alia_: one interesting thing about Push is that you _can_ run it in isolation
... it gets tricky when you talk about other events like fetch or notificationclick

JakeA_: need to look at the order of things; when the window is opened from the notificationclick....
... I wonder if we could tie it back to the fetch somehow....

n8s_: for open windows, if you expose the controlling SW, and if SWs can talk to each other...

hober: it's worth pointing out that there might be a world where you have notificationclick w/o ever getting a push event

JakeA_: from what I've understood is that Safari is asking for declarative push where a push message will lead to a push notification w/o running the SW
... MSFT wanted something similar?

jmann: yes

JakeA_: it's something we've pushed against because it's a worse user experience....you see a notification when you're offline and the app fails

https://github.com/w3c/ServiceWorker/issues/1091

JakeA_: the goal here is to give develoeprs as much info as possible about which client made a fetch and, if it's a navigation, which client will be replaced by a fetch
... and if it's a new window, which client will be created by a fetch
... we had an idea of a reserved, target, and <other> client
... ran into trouble regarding `about:blank`; browsers create these documents interoperably
... does Edge do this?

alia_: don't know.

JakeA_: it's something that's in the spec

wanderview: yes; Remy Sharp uses this on old IE for jsbin

JakeA_: in the tests we threw together, I couldn't get Edge to do it
... to work around it, the names we came up with were:
... "clientId", which represents client that made a fetch
... "resultingClientId" which, if it' s a navigation, is the client the page will go into (which can represent an already-existing `about:balnk` page)
... and `replacesClientId` which is the client that will go into history if a navigation is successful

jungkees: would like to discuss if exposing this is what developers really need
... would like to discuss background and spec behavior too
... implementations aren't compliant today. Initial `about:blank` is reused in iframe case. Perhaps the global itself is created when the tab is created for the iframe/aux-browsing-context, and the JS is creating all teh state in the global
... when the page in the frame is created, a different global should replace the existing global
... but in these cases, the JS execution creates states that perhaps shouldn't be replaced
... we have 2 such cases:
... "static iframe", initial document in an iframe ha the same origin as the parent global
... "window.open" in the same circumstances
... in all the other cases, we don't have the same corner-cases
... that's the curent spec behavior, so I'd like to talk about the extent to which we want to expose these to developers
... from that point we can discuss the extent we want to expose `reservedClient` to the API

JakeA_: there are 2 rough choice; we can build an API that pretends all this weird stuff doesn't happen and protect developers from it. Else, we can describe exactly what's happening

JakeA_: so a same-origin navigation will either blow away the gloabl or keep it; it was there to keep some global state
... it was there to pretend to developers that iframe loading was asynchronous
... I'm worried that if we add features, we're going to add more edge-cases
... if we could go back, I'd like to remove this behavior. I'd have given folks a load event or promise instead

slightlyoff: perhaps worth separating acknowledging the edge cases vs. API design that tilts things a particular way in the future

JakeA_: we're gong to have to write _somehow_ that this stuff indicates what the browser does
... and with what we've spec'd so far, you could end up with the `clients` API lying to conform to the spec, but wouldn't be in sycn with the implemented behavior
... we could put notes in the spec to make sure they don't get out of sync?
... one of the thigns that came out of wanderview's work around this are questions around `reservedClient`
... durring navigation we'd give you an ID of a client that does exist in the weird `about:blank` cases and in other cases is the document that *would* be created
... <discusses other cases when you wouldn't actually have clients>
... we had an idea that we'd give you an object that represents what we knew
... and a `postMessage` interfaces that buffers
... a lot of these questions from wanderview imply fudges in the spec to have objects that don't represent real things

wanderview: they're fairly unusable for anything but `postMessage`
... the proposal you mentioned elsewhere, just delaying `clients.get()` instead, makes more sense to me
... a thing that would need to get spec'd is when that happens

jungkees: falken can you discuss chromium behavior?

falken: I agree it seems easier not to expose that object
... I agree with ben

*wanderview

JakeA_: so the proposal is that instead of exposing that object, `clients.get()` would wait to resolve until the client actually exists
... this gets us out of `postMessage` queueing

etc.

slightlyoff: what do we lose? what information can't you get any more?

JakeA_: if you write a fetch handler that wants to wait for a resulting client (because the developer needs to send a response), it'll deadlock
... i'm sort of happy with that because the deadlock case is the common case
... this eliminates the existing client being a hard-to-discover edge case
... are there objections to doing that?

wanderview: I think it's prudent, given the list of issues
... I like what jungkees has added regarding `execution ready`
... want to still build on that

wanderview: doesn't get us out of *all* the weirdness because `execution ready` will immediately apply to the `about:blank` document which will shortly get different URL values
... I like modelling what the system actually does

JakeA_: in the `about:blank` case, there's a very real client already (in teh edge case), or in the replaced client you'd actually have it

wanderview: one issue I had to deal with was, per spec, to create the initial `about:blank`, but we try not to if nobody ever touches it
... exposing this optimisation isn't great
... I create a client w/o creating a global. If you touch the client, then we create the global

JakeA_: so this creates the global if you `postMessage`?

wanderview: yes

wanderview: it's a brittle optimisation; it tends to regress because people call the wrong method

alia_: so is this synchronous?

wanderview: need to look at my code

jungkees: in the spec, the `exeuction ready` flag is set just before the script can be evaluated, after teh global and document are created

JakeA_: in terms of naming the IDs, are we still happy with `clientId`, `resultingClientId`, `replacesClientId`?

slightlyoff: can I have all 3?

JakeA_: you can; imagine an iframe on a page to something on your origin and you click a link that loads in the iframe

wanderview: <brings up worklets>

JakeA_: is that one fetch?

slightlyoff: it's zero fetches

wanderview: outlines worklet lifecycle, owning document populates the worklet

JakeA_: there's an issue already about wether or not worklets are subresources or clients...

wanderview: I think we said they were subresources
... it's a new case where subresources are creating globals

JakeA_: something to think about in the future

wanderview: something to discuss about what `import()` should do

JakeA_: I think it says fetched-once, instantiated multiple times

falken: do we need all 3? internally people rally want `resultingClientId`
... and that's what I'd implement first
... does it make sense to spec out all the details if we aren't going to implement it first?

JakeA_: if developers can tell...e.g., if they're `null`
... not being able to tell the not-implemented from cross-origin client case...
... n8s_ is this something you need?

n8s_: generally useful, but we've built workarounds

JakeA_: we've looked at this in terms of AppCache
... and for that, `resultingClientId` is the one we'd really need

alia_: do you (wanderview) support `reservedClientId`, etc. today?

wanderview: no, I've been working e10s support

JakeA_: break?
... 15 minute break, start back at 10:20

break

https://github.com/w3c/ServiceWorker/issues/1123

JakeA_: this is about reserved clients, which we just killed, but there's still an issue about getting ahold of a client object which is already navigating and navigating it somewhere else

wanderview: how can you do this?

JakeA_: <explains>; you can do this already by changing the source of a client mid-navigation, so browsers already handle this?
... alia_: you wrote the original issue for this...

wanderview: I thought this was for calling `client.navigate` on the reserved client itself?

JakeA_: so should it be ignored? something else?
... so we came down to "we have this problem already"

jungkees: that was my last comment on the issue

JakeA_: are we happy that we're covered spec-wise if you call `navigate` twice?
... I think that abort-and-navigate is what iframes do now?

falken: so the desired behavior is that you throw away the existing navigation and start another one?
... internally, we hear that developers want to detect a "stuck" navigation and redirect to somewhere else

alia: meaning that you'd cancel in-flight?

falken: yeah

alia: so would you still surface the fetch event?

wanderview: you can force this to happen by hadling a navigation fetch event and before you `respondWith`, navigate the client....
... sites could already be doing this on purpose
... maybe it's a cross-origin thing?
... they could do a redirect....

falken: so maybe you detect a navigation that's slow and navigate away to a fallback

wanderview: so that can happen with `abort()` from `fetch()`?

JakeA_: the benefit of doing it from the client list is that you can do it from afar

wanderview: could do via postMessage?

slightlyoff: but you need cooperating script to have loaded....

wanderview: we should probably write a WPT?

JakeA_: so the use-case is:
... you've decided to respond from the network, get headers, but then the connection gets stuck...then you want to switch then
... so the only way to start again is to navigate away
... so you could use postMessage, but you're relying on the page
... to be booted up enough
... <writes down resolution>

wanderview: thanks to Chrome for upstreaming your WPT test
... has been very helpful

alia: yes, thanks

falken: thank you for upstreaming in the first place, wanderview!

wanderview: it was really encouraging to see WebKit serving Cache Storage in a TP
... when CacheStorage was shipped in FF and Chrome, there are some holes in the tests there
... I think there are some missing tests, e.g., storing more than one header based on `Vary` headers
... or that the Response objects stay alive after you delete from Storage, e.g.
... so want to flag that for new implementers

alia: <tests for cache size figerprinting>

wanderview: in 58 or 58, we've got a fix in

Josh Bell: we have a fix in as well

wanderview: I let Unif know about it too

JakeA_: do we think that fix is something we should put in the spec?

slightlyoff: lets make sure it's in tests first, then we can decide about spec-ing it

alia: so perhaps a non-normative note?

JakeA_: diversity in the fixes is beneficial...

<wanderview> Sorry... not sure if I am pronouncing his name correctly... "unif" is Youenn Fablet

thanks, wanderview

Josh Bell: we're starting to look at when quota changes in response to exogenous actions. MOre documentation for developers in this space will be good

JakeA_: is it different between browsers today?

Josh: almost certainly

Josh Bell: only 2 browsers implement this, and only one has shipped

https://github.com/w3c/ServiceWorker/issues/1204

JakeA_: we have an idea today of resurrecting unregistered SWs
... clients that are controlled by an unregistered SW are still controlled by them
... ...and if you call `register()` again w/ the same options, it'll bring the old one back to life instead of creating a new registration
... wanderview created an issue here about the various lifecycle points happening in odd ways (no `install` event)
... is resurrection not what we want?
... it's a pain for tests

wanderview: yes

JakeA_: I think folks would be surprised by this

n8s_: yes, very confusing
... to fully solve it, you have to post a message
... you end up working around it

slightlyoff: do we agree this is bonkers?

jungkees: wanted to talk about deleting the registration, which isn't synchronous
... if a user opens up multiple clietns that are conrolled by the same SW, we don't know when to delete
... if script repeatedly unregisters and re-registers, we have to queue them
... if we do this with resurrection, nothing happens when we have the queued tasks
... I don't understand why it's a problem?

JakeA_: I think there's a developer expectation that when you call `register` the first time, you're going to get the install, etc. events
... from then on, it's a no-op if there's a matching registration
... but if you call `unregister`, there shouldn't be a matching registration

wanderview: but what jungkees says raises a problem....if you get rid of this concept and isntall a second SW w/ the same version of the script, you might stomp on storage

n8s_: I don't think you're going to get rid of all the edge cases here
... it's more clear to develoeprs that the install events will fire again

alia: what about `unclaim`?

JakeA_: we've discussed an option to unregister like this

wanderview: if we fire events again, we could put a flag on them that says "this is a re-installation"
... then they could look and see if it was different...

n8s_: I think for the most part, people do this wrong today

wanderview: do we know how many sites use unregister?

n8s_: we use it

falken: don't think we have metrics for this

alia: what do you use it for, n8s_?

n8s_: it's a bit of a sercurity feature, e.g. if an extension deletes a cookie underneath a registration
... there are lots of cases where we hit a path were the SW is like "oh, I'm not supposed to be here any more"

JakeA_: are you doing "unclaim"-like things?

n8s_: we'd do a refresh
... not sure it would be useful in those cases

alia: so you don't just unregister, you also refresh?

n8s_: yes, and for notification stuff

slightlyoff: have you looked at `Clear-Site-Data`?

n8s_: wasn't very far along....

slightlyoff: it disconnects tabs from storage entirely

n8s_: sometimes users toggle things in settings that cause a SW to be unregistered and re-registered
... in those cases we get some things wrong and just refresh

JakeA_: is the problem that `unregister` + `register` is a no-op? or that it doesn't create a new registration?
... we could treat it like a differet registration (re-fetch SW, etc.)

alia: so this would mean that you'd have the old one hanging around
... and then you'd have to claim

n8s_: this might not work for mashing a settings toggle

jungkees: so old clients are still handled by the active worker from the old registration....
... e.g., if you change `updateViaCache`, that's a new registration, so that's a differetn case....

JakeA_: yes, but asking if we could treat it that way

wanderview: my concern is the new one camping out on the old one

*storage

wanderview: but not a problem if you `skipWaiting`?

jungkees: so that means that if the developer doesn't call `skipWaiting`, things might be broken for existing tabs

JakeA_: and that's what happens now if you change something in the settings object?

alia: so this is like a forced-refresh scenario

JakeA_: we've had an issue about calling `skipWaiting` from the page...
... we've been lukewarm to it before

slightlyoff: how is this connected to the previous conversation?

JakeA_: so this unregister/re-register acts like a forced update

wanderview: maybe a `reactivate` event?

n8s_: that might be best; it explicitly calls out to developers that this is a case to think about

jungkees: in the timing where we set the unregister flag, we can queue a task for firing this event

wanderview: but they haven't become unactive....

n8s_: if you unregister a SW from a client, you have to tell the SW

wanderview: if you persist the state, the SW might go awya if it's stopped

jungkees: this event could give you more information in the event handler

JakeA_: so we've talked about the developer headache...not sure how a re-activeate event fixes it?
... it gives us a place in MDN/in-the-spec how to call this out?
... what would developers do here?

n8s_: reinstall cache, re-activate, call claim

alia: how would it be different than an `activate` event?

slightlyoff: so it has to be extendable

<room: yes>

slightlyoff: do we like this? hate it?

JakeA_: not sure it solves thigns for developers...

n8s_: but this gives us a way to `claim` stuff

alia: maybe we could add stuff to `activate` instead?

n8s_: this is pretty different

wanderview: will this confuse developers about SW restarts?

JakeA_: the naming's wrong...it was already active

slightlyoff: "revivify"?

wanderview: this is a pretty minimal change to accomodate what we already do

JakeA_: the reason we're not looking at removing resurrection is tabs which are alive after unregistration...

wanderview: and you can fill up your job queue

JakeA_: but if you're creating new registrations, you just create lots of them?

jungkees: if you have many queued tasks, that's about the user interaction about tabs being closed

falken: you could block re-registration on the unregistered SW actually going away?

alia: hey Josh, what happens when you try to re-open a deleted IDB?

Josh Bell: in theory, deletion creates a queue, so a re-open re-creates at version 1

JakeA_: but with Cache API, you can get ahold of an item that nobody else can see and then creating one of the same name can Just Work (TM)
... so consensus is that removing resurrection isn't as good an idea as we thought it was?

slightlyoff: there was enthusiasm for an event?

n8s_: seems easiest, developers reading through docs will help them

jungkees: naming is wrong

n8s_: "resurrection" sounds clear?

falken: but you wouldn't get that event for a different SW on the same scope?

n8s_: no, that's a different registration

JakeA_: but there's a case where you call unregister then change an option (script URL, or `updateViaCache`)...that resurrects

jungkees: `updateViaCache` is in the registraiton, we see that as a different registration

jungkees, wanderview: still an open issue

JakeA_: right now, if I call unregister, then I call register with the same scope but different script URL, do I get the same registration back?

falken, Mek: yes

JakeA_: but in this event we're discussing, we're looking a the resurrection of a SW, not the registartion....

Mek: that's part of it

wanderview: in terms of the events, we fire it on a SW, not a registration

JakeA_: how would we describe this event?

n8s_: we'd define it narrowly: when you wouldn't get `install` and `activate` becuase it was previously active

Mek: but what about the old one that could be controlling stuff?

wanderview: we don't have "registration create" and "registration deleted" event type

Mek: even though the old worker is going to be replaced, it's still alive from it's perspective, tho

JakeA_: if we have this event, it has to happen on the active worker regardless of option changes, otherwise it's weird

n8s_: that makes it really clear what's happening

Mek: there's still the weird case where you register a URL that doesnt' really exist....

n8s_: that's sort of orthoginal, but seems buggy

asuth: so what happens to thigns like background sync, push registrations, etc.?

JakeA_: it's all still there, comes back a well becsause it's tied to the registration object
... really struggling with this one
... I sort of feel like creating a new registration is easiest to explain, but I get the edge cases

wanderview: this all falls out of async registration

slightlyoff: the only other option is that you e.g., gray out all your windows

JakeA_: so unregister and unclaim?

slightlyoff: yeah, but then you're just breaking sites

falken: I think a summary is "we talked about 5 different things and none of them are perfect"

slightlyoff: there's a lot of missing detail in these notes, please fix

asuth: as a question for other implementer,s do you store things like webauth on the same store as your registration store?

falken: mostly. We have a database of registrations and we can add user data to those entries
... implementers can add stuff, e.g. keys to other dbs

asuth: so like a foreign key db?
... 'cause ours is a mess, just a scope

JakeA_: in the past, when we've gotten stuck on developer expectation, we've gone and asked developers...maybe we should do that here?

asuth: I hear you volunteering....

JakeA_: ...yeahhhhhh....

<link rel="serviceworker">

context: https://github.com/w3c/ServiceWorker/issues/1207

Mek: we should get rid of the header parsing of sub-resources

JakeA_: so if we did keep it, it'd be for navigations
... Anne was interested in things that were diffrent to JS registration

<JakeA_ describes what Anne wants>

slightlyoff: I like having the header registration version, but I don't think we should ever block on install

JakeA_: the best argument I've heard about this is from CDNs who want to auto-register SWs
... they'd rather inject a <link rel="serviceworker"> to injecting script

slightlyoff: would they prefer a header?

JakeA_: I think so

slightlyoff: would upset CSP

Mek: header would be easier

hober: why not remove from spec and see how loudly people complain?

wanderview, JakeA_: <conversation about modifying content>

slightlyoff: we have andrew betts here, we can ask CDN folks this week

wanderview: also, Yoav!

JakeA_: should we keep `InstallEvent`?

wanderview: we could just use `ExtendableEvent`

RESOLUTION: we're going to talk to CDNs more and go back to using `ExtendableEvent` (killing `InstallEvent`)

https://github.com/w3c/ServiceWorker/issues/1191

JakeA_: so this is a case where you don't call `respondWith` but still read the body of the request

wanderview: in the fetch event handler, if you don't call `respondWith`, you mark the body as `dirty` so that if you're in async work, you'd get a rejection

(this is on the `Request`, not the `Response`)

JakeA_: there are cases where you might have the POST happen again....this was an issue with Streams

wanderview: same problems with readablestream on POST

falken: we have the same concern for a redirect that occurs after we sent the request body the body to the SW
... so if a redirect occurs we can't issue a redirect w/ the body
... this _might_ be what the Fetch spec is saying, but it's too hard to understand

Mek: Fetch has 304, 305, 306 them repost

wanderview: 301, 301, 303 redirects to a GET

<conclusion: you need to `clone()` to avoid breakage>

<falken> scribenick: falken

"Use the URL from the response"

wanderview: should the response use the URL of the request or the response. paths should be relative to response location or the original request.
... CSS has this problem with @imports. workers have the issue with importScripts(). document... ?
... fetch a worker script from a different location, and return that. not a synthetic response. a response from a fetch.
... because of that we made the spec change. the spec used to say always overrite with the response URL. but now we want to change the spec to say only when URL is an empty string.
... no one implemented the original spec. but chrome implemented it in some cases.

falken: i don't really know...

wanderview: chrome seems to not do it in general but in some case.
... problem about CORS cross-origin response, and pass it to respondWith, the worker script might end up with a cross-origin URL, normally worker scripts are required to be same-origin...
... are we still sure we want to do this...

JakeA_: if the request is same-origin, i thought we would fail on cross-origin responses. or is that only non-CORS?

wanderview: we don't fail CORS ones since you can get the body out you can synthesize your own anyway.

wanderview: anne seems to think it's fine as-is
... an idea: if response is empty string URL, set it to request URL.
... that's what we do now. and we could also force it if it's a cross-origin response

JakeA_: or we could fail

wanderview: might be a breaking change

JakeA_: not sure if people are doing it

wanderview: been out there for years now

slightlyoff: could collect data

JakeA_: goal is the pass-through case.

wanderview: want to fix this: in pass through sw today, the inner fetch does the redirect but outer side doesn't see the redirected url

JakeA_: today if i do new Worker(url) and the url redirects cross-origin, no sw involved, does that fail today?

wanderview: importSCripts() can definitely redirect. i think top-level are not allowed to.

wanderview: css can redirect

JakeA_: that works fine according to the spec. it doesn't matter because it uses the response url.

wanderview: if we implement this change
... i don't know if there's another way to get a cross origin worker script. we'd have to poke holes in our security mechanism to do it. which we can do.

JakeA_: seems fine....

wanderview: classic worker script, dedicated worker today needs to be the same-origin. if we do this change to allow cross-origin script, the worker's self.location will become a cross-origin url.

wanderview: would feel more comfortable if outer url is same-origin

JakeA_: can't really think of an attack that this allows
... you're already deliberately pulling scripts from cross-origin

slightlyoff: consider if iframe sets document.domain to be its parent origin... can it confuse itself/parent to do this to allow cross-origin responses
... confusing document about where it's really from is always a bug farm

wanderview: poking holes in our security mechanism is pretty worrisome
... also passing through redirect flag from the response

JakeA_: with documents, if you pass through a redirect response it'll still use request url for the base right? navigation algorithm uses final request url as its base.
... this is only a question for workers and stylesheets (stylesheets seem behaving as intended because they can already be cross-origin).
... if we had to change something here, I'd rather we require you to create a synthesized response. don't feel strongly.

alia: would have to look at our implementation

horo: we are checking response url. if sw returns cross-origin response.. we reject it

wanderview: checking for what constraint?

horo: same origin and csp

wanderview: would you bypass that same-origin check?

<horo> https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/loader/fetch/ResourceLoader.cpp?type=cs&sq=package:chromium&l=549

https://github.com/w3c/ServiceWorker/issues/1213

JakeA_: when waitUntil will stop taking new promises. we made a spec change to allow passing promises to event.waitUntil until all promises are done.
... some interesting timing around this.

JakeA_: event.waitUntil(p); p.then(() => e.waitUntil(q)); should fail

p.then(() => event.waitUntil(q)); event.waitUntil(p); should work

mek, asuth: implementations are intentionally doing something here

jungkees: there are tests about this
... have to decide about whether to throw or not
... whether to throw in JavaScript

<jungkees> https://github.com/w3c/web-platform-tests/blob/a16738c524a65946b0ff7df6be37ae076ff5e860/service-workers/service-worker/resources/extendable-event-async-waituntil.js#L33

<wanderview> horo: falken: looks like same-origin fetch() still accepts a cross-origin CORS Response from the SW: https://sw-passthrough-redirect.glitch.me/

<wanderview> in chrome I mean

mek: the test is broken because everything is written in the same test

jungkees: question is whether we 'll disallow waitUntil in every async task including microtask?

wanderview: our impl is oriented towards once you start holding it alive... once those promises settle.... we won't let you then bring it alive again... even if you're in the same dispatching task...
... we don't honor dispatch flag after previous promises have already settled
... not really looking at dispatch flag. initial one has a token. then we add stuff to the token.

Mek: multiple event handlers?

wanderview: would have to look
... would like a WPT for that case
... would rather implement to a WPT then make the spec match that... it's hard to reasson about the spec.

jungkees: we already have the wpt

wanderview: but they were written without dispatch flag and promises as microtasks

<jungkees> https://github.com/w3c/web-platform-tests/blob/a16738c524a65946b0ff7df6be37ae076ff5e860/service-workers/service-worker/resources/extendable-event-async-waituntil.js#L20

JakeA_: I expect this should pass, but test is asserting failure.

wanderview: going back to same origin fetch... chrome allows cross-origin cors response
... this is cross-origin response for fetch()... ideally workers and css would behave the same way

JakeA_: could run this by mkwst et al

<break>

hober: i asked yoav about the link header-based installation thing at lunch. seemed a bit ambivalent. liked the idea in the abstract more than something in actual practice.

slightlyoff: andrew (fastly) at lunch said he wants this. doesn't want to touch content at all. would like a header version.

https://github.com/w3c/ServiceWorker/issues/719

JakeA_: we failed to get chrome security folks opinion on this
... possibly violation of same-origin policy... been doing this a long time... no security incidents that i am aware of

wanderview: we'll do what other people do... fix used for perf timeline isn't really right
... jonas argued it wasn't worth the complexity because stylesheets are leaky already
... anne has a point that we shouldn't make things worse
... not a big priority since we've known about it for a long time, no one has fixed it

slightlyoff: will ask security folks

wanderview: every time we've talked about this we try but haven't gotten a response

slightlyoff: would like to know if anyone thinks if a big problem that needs fixing

wanderview: haven't gotten guidance from our security folks

s/security wg/webappsec/

wanderview: talk of workers as subresources. opens up same problem as stylesheets.
... can be cross origin, have resources underneath it.

workers as subresources

JakeA_: .... if they call fetch()... or create an image element...

wanderview: ... that doesn't apply if you allow top level script to be cross origin... it'll be the one owning the top level global....

JakeA_: unless we required cors in which case it's script visible anyway

https://github.com/w3c/ServiceWorker/issues/1189

falken: thread seems converging on making it a live property on registration

wanderview: we don't fully implement it but we'll do this

falken: register() same-script, change updateViaCache, do we install a new worker?

https://github.com/w3c/ServiceWorker/issues/1200

mek: spec has the behavior to do it for all functional events

falken: can the spec just make the optimization optional?

jsbell: async cookie api will want this

brady: support we have a sw script without fetch event or message event handler. but it does do some indexeddb stuff. and in response to indexeddb update it installs a fetch event handler.

JakeA_: the intention is we throw if you add event handler asynchronously after the initial script evaluation
... given that impls so far only do it for fetch... maybe spec should allow it only for fetch...

falken: or just make the whole optimization optional...

JakeA_: not sure it's ok to have that much wiggle room

wanderview: would be ok to add something to Dispatch Event saying impls may abort these steps if they see sw doesn't have a handler for the event

jmann: feels like impl detail

JakeA_: going back to cookies. is that using event listener or...?

jsbell, mek: using both...

jsbell: during install event... registerCookieChangeInterest....

<jsbell> https://github.com/WICG/async-cookies-api/blob/gh-pages/explainer.md

JakeA_: explicit api so probably don't need to worry about it for the optimization

n8s: using polling... pretty awful

https://github.com/whatwg/dom/issues/371

jungkees: we did this optimization for fetch... needed to do this
... special case

Mek: some people were talking about unit tests that create events and their own event listeners later

JakeA_: would like to know real use cases

slightlyoff: webappsec people will look at the issue from earlier

https://github.com/w3c/ServiceWorker/issues/204

slightlyoff: we shouldn't unregister

n8s: agreed. there are times when 404 and other server errors happen and we wouldn't want to unregister

slightlyoff: happens in google infrastructure too

n8s: can implement this using onupdatefound too

slightlyoff: would be fine with extending this for the service worker header or as an option on register
... wouldn't want to swap the default though

n8s: people that really need this can build it

wanderview: flip side.... i had a profile on firefox that had a google plus sw... they did an experiment then walked away.... the sw never went away... continuously did 404... using my client resources...

jmann: agree with alex....

slightlyoff: dns...... you might 404 because ownership changed....
... maybe browsers should get smarter about dns changes....

wanderview: still getting 404s from google plus... not a theoretical problem...

range requests

n8s: facebook does this intentionally

JakeA_: seems like we can't change browser behavior without breaking things
... might need mitigations when it goes through a service worker

JakeA_: want to enable range requests to go through sw which they currently don't.... restrict it to range requests that came from the browser
... should go through this with anne

image caches issue

alia: implementations have different behaviors about caching images
... sometimes chrome doesn't surface a fetch event because image is cached

wanderview: firefox does the same thing
... both chrome and firefox avoid sending fetch event to sw

alia: different levels of caching

wanderview: i wrote a test

<wanderview> https://sw-image-cache.glitch.me/

wanderview: there are three images where it loads in parallel (no-wait) vs sequential (wait). to show overlapping vs non overapping requests. chrome and firefox only get two fetch events in this case.

alia: thought i saw something different

JakeA_: memory caches that sit with the page/client... always come before the service worker... don't know about link rel=preload

wanderview: image cache has a spec. ours is apparently not totally spec compliant.
... would be nice to clarify intent

slightlyoff: came to some agreement that we should provide a flag for controlling this if it becomes an issue

wanderview: question is whether cache control header an adequate signal for these high level caches
... these high level caches aren't specced

JakeA_: don't know if preload has gotten any better... anne interested in it being specced

youenn: on navigation fetch are you bypassing memory cache?

JakeA_: bfcache?

wanderview: we do not issue fetch event if restoring from the bfcache... no network request at all
... there are cases where we evict from bfcache like if sw is no longer active...
... don't have an equivalent to chrome's memory cache... just have caches for certain resources

slightlyoff: we don't cache all resources too i think

slightlyoff: heuristics about when to generate and store parsed/compiled bytecode

wanderview: as far as this discussion goes, doing it in cache storage or http cache, something that lives below sw fetch event vs above...

slightlyoff: blink memory cache seems to include images, stylesheets, scripts, xsl stylesheets, fonts

Request.navigationType <https://github.com/w3c/ServiceWorker/issues/1167>

JakeA_: lots of developer interest in this
... remaining issues: should back/forward be different values?
... navigation timing spec has "back_forward"

falken: internally blink/chromium doesn't distinguish but seems like it should be implementable

slightlyoff: pretty convinced that a conjoined back/forward would solve most of needs of developers who have been asking for this

JakeA_: probably need justification to diverge from navigation timing

jmann: could always have another property to break them out

JakeA_: in mozilla it's not a problem for back/forward to be separate?

wanderview: feel like our impl must be separating them somehow

jmann: not sure if there was a reason that nav timing did it together

JakeA_: ok do back_forward now and we can split it out later using a property?

jungkees: put it on request vs in FetchEvent?

wanderview: we already have state on Request
... cache...

JakeA_: destination is similar

wanderview: mode says 'navigation'

hober: we need to distinguish form submission too

slightlyoff: might want a list and not a single value...

JakeA_: it can be reload + form submission

brady: yes we have a flag for that
... also we distinguish navigation programmatic vs navigation due to clicking a link

slightlyoff: we'd probably only show that in same-origin navigation

brady: sure, yes

slightlyoff: feel like we need an extensible list

jmann: this list doesn't match nav timing already because we don't have prerender

slightlyoff: we are probably removing it too

JakeA_: what would this be called...

Mek: it could be boolean flags

<calls to call it "history"

wanderview: would these be set for workers?

JakeA_: no

wanderview: keeping on request is best because otherwise it'd get lost during pass-through

CR

JakeA_: we want to start the path to CR sooner than later
... seems like we have only gnarly small bugs remaining

jungkees: just have to do clients api and navigation hook

JakeA_: any objections to starting the process?

jmann: are people supportive?
... i support it

wanderview: feel like we still have some breaking changes but...

jmann: seems ok...

jungkees: my primary concern is after cr we will have to do ??? normative references to html ... hooks to whatwg html

Mek: cache api should be its own spec?

jmann: blocked on logistics?

<...exclusion procedure...>

MikeSmith: will double check on this

jmann: we're just trying to figure out the process

https://github.com/w3c/ServiceWorker/issues/1195

n8s: there are times the client or service worker knows the sw doesn't have anything to respond with
... would be nice to remove sw from critical path until it's updated. but not unregister
... would be nice to remove fetch listener until update with fetch event

JakeA_: we have mode on request

n8s: would be nice to expose that yea

JakeA_: it would help for fetch() but not image/css...

wanderview: or attribute on page

JakeA_: common cases other than fetch api?

n8s: everything... resources we know that won't be there... javascript, static videos/images...

JakeA_: and these are picked up by the parser.. so creating a request object is slowing you down anyway

n8s: add fetch options to these?

slightlyoff: csp has its own parser... style...

JakeA_: clear-site-data was a header with a json object.... changed to list of items

jmann: you want to indicate that you don't generate fetch event for this class of resources?

n8s: yes that would be useful to start with.

JakeA_: we have a lot of fetch options and exposing them seems reasonable

jmann: why json and not a list?

JakeA_: name-value pairs

wanderview: fetch options lets you set headers. do you really want that?
... now it'll affect sites more than those that have a sw

JakeA_: in html, can we even have newlines in the middle of attributes?

MikeSmith: it'd be preserved... nothing in parser algorithm strips newlines out

jmann: do we agree it's a good concept? anything bad you can do with it?

n8s: already have a sw...

wanderview: may have things to think through with cors and no-cors
... big difference between allowing something with sw vs allowing it everywhere

JakeA_: spec would create the request object as we do now....

wanderview: easier path forward would be to design it so we can add the fetch options later, but first do it for service worker bypass only

n8s: seems fair and also useful

slightlyoff: what syntax is feature policy using?

JakeA_: csp-style syntax

wanderview: doesn't need to be json but something extensible

asuth: would we allow csp to turn off the bypass? use case of sw as cryptographic code signing magic security thing?

JakeA_: embed tag and others bypass the service worker

n8s: maybe could be something added later. page can already unregister the service worker and refresh itself...

JakeA_: which issue of #1026 and #1195 should we pick to talk about?

n8s: #1026 seems more important
... we play tricks to make update happen faster but there is still a delay
... developers might not expect that addEventListener after install to fail

slightlyoff: thinking of it in terms of symmetry: way to turn it on and off

JakeA_: this api would be exposed outside the sw as well

wanderview: 1195 seems a little niche compared to other things in the web platform
... our update mechanism is the way to update the persistent state of the worker
... adding switches that can be flipped and change persistent state makes me a bit uneasy

slightlyoff: related question about pathologically slow service workers at 99 percentile... how aggressive can we be about mitigating those

wanderview: im more inclined to accept 1026 since it's already something we're having to do

JakeA_: agree with the flipping switches thing... something we went down with navigation preload... would prefer to keep state with a service worker

adding clients api to window

n8s: absolutely have uses for this
... not super critical since we can always ask the sw... but not so nice
... would be nice to have on window but not super critical

wanderview: can use clients.openWindow instead of window.open, nicer api

JakeA_: have to keep this in mind so we don't put anything on clients api that would prevent adding it to window

wanderview: postMessage goes to container....
... exposing sw clients.... would at least like to have the service worker as part of the enumeration... we use the enumeration internally...

JakeA_: not against that at all
... but wary that it start exposing stuff we're not sure of regarding multiple instances

wanderview: matchAll with service worker type

n8s: interesting things are fetch failures... clientcontrolled...

jungkees: talking about lifecycle events

clientcontrolled #886

slightlyoff: lifecycle events fired inside service worker?

JakeA_: they will be on the document

wanderview: chrome plans to stop http frames?

slightlyoff: interest in moving everyone to tls

wanderview: what i like about lifecycle is it looks like it's defining good primitives that can work for not only their use case but also things like bfcache and we can have a more coherent model

JakeA_: problem with uncontrolled. what if page is being torn down because of resources. don't want to spin up a worker in that case.

slightlyoff: these things are advisory. similar storage exhaustion/fd description exhaustion. at some level you'll get a hard error. you should get these events before the hard error.

wanderview: i do know that bz involved in lifecycle stuff, he might have opinions.
... he would prefer page event

n8s: would this be hard for microsoft or apple in a world they have multiple sw instancse?

brady: we'll see when we get there

recovering from failures/tab crashes... #939

JakeA_: suspect not a lot has changed since april

wanderview: someone creating a sketch of what they wanted would be the next step

JakeA_: that worked well for nav preload

n8s: yea other things are priority first

alia: talking about performance issues... folks saying sw is not as good as appcache
... people still using appcache for perf
... might need to think more about this static routing thing for sw

JakeA_: resulting client id... may let you build polyfill of appcache

performance and static routes

JakeA_: with appcache polyfill we can measure more clearly the perf difference

Mek: worklets for the routes

asuth: firefox was experimenting with racing http cache with network

n8s: we see pathological case of http cache on chrome we don't see in others

<end>

- DRAFT -

SV_MEETING_TITLE

08 Nov 2017

Attendees

Contents