<JakeA> https://github.com/w3c/ServiceWorker/issues/1094
wanderview: is there anything we want to make sure covered? foreign fetch?
JakeA: yeah foreign fetch. anyone with requests?
falken: navigation preload?
JakeA: Just wanted to make sure we have V1 covered
Domenic: deprecate appcache? :)
JakeA: we should do that.
surma: [reloading fetch?]
JakeA: annevk posted on it yesterday in more detail, we should have a look
<chaals-ordhord> https://github.com/w3c/ServiceWorker/issues/1094
<chaals-ordhord> JA: There are various places where you should act as if there is no SW
<chaals-ordhord> ... there are some complicated cases.
<chaals-ordhord> ... we made decisions, but nobody has implemented. fetch.request will fail
<chaals-ordhord> Ben: We didn't do this in gecko because there are missing pieces
<chaals-ordhord> ... we will probably do it, we don't think it isn't valuable
wanderview: why we didn't implement this in gecko we need some [extra infrastructure]
<chaals-ordhord> ... have heard from developers they need mixed content.
<chaals-ordhord> Salva: usecase - podcast app. even if content is passive you need to call it through http
salva: one usecase e.g. for a podcast app, you don't want to proxy everything through https
<chaals-ordhord> JA: had people try to make podcast example. CORS is also an issue e.g. RSS feeds
<chaals-ordhord> Ben: You could do it with CORS, mixed content warning was the blocker
<chaals-ordhord> JA: standalone app would have that too.
<chaals-ordhord> Salva: problem is the crawling model.
<chaals-ordhord> JA: Even if we implement this, PWA will get scary warnings. plan is to prevent downgrades like this. Do we mark it as at-risk?
JakeA: the plan is to eventually prevent downgrades like this
<chaals-ordhord> Ben: No strong opinion as implementor. Maybe we just don't do it, developer feedback is what matters.
wanderview: consult the web dev community, see if they accept this as a limitation?
<chaals-ordhord> N8: facebook doesn't want mixed content warning.
<chaals-ordhord> Ben: Maybe remove it with note that says this is possible but isn't implemented yet.
<chaals-ordhord> Falken: Surma filed bug in Chrome. Do you recall a usecase?
<chaals-ordhord> [chrome bug 614375]
https://bugs.chromium.org/p/chromium/issues/detail?id=614375
<chaals-ordhord> Surma: working with opaque responses. images...
<chaals-ordhord> ... so I would get blocked. We should be able to cache opaque response
<chaals-ordhord> Ben: You can do it from a page, not from an SW
surma: I got blocked... if it was an opaque response one should be able to cache it anyway
<chaals-ordhord> Surma: yeah. SHould propogate mixed-content state, but show the image.
<chaals-ordhord> Salva: @@
<chaals-ordhord> Ben: Should we say that you can't have it?
wanderview: I wouldn't have a problem--but couldn't implement just yet due to infra issues
<chaals-ordhord> JA: You mean if it fails, pass it through fetch, or prevent mixed content
<chaals-ordhord> N8: Let people do it through fetch.
<chaals-ordhord> ... don't call RespondWith
<chaals-ordhord> surma: So then you cannot cache it?
<chaals-ordhord> JA: Right. If anything mixed is in the cache you display warning.
salva: so we are not blocking?
<chaals-ordhord> ... if you want to display mixed content, if the request is http: don't call respondWith.
<chaals-ordhord> N8: that's safer.
wanderview: but then you can't do anything
n8s: and it's fine, as it avoid a whole many other issues
<chaals-ordhord> [only passive mixed content goes through anyway in other methods]]
salva: we can inform the user that for such content is not available offline
<chaals-ordhord> n8s: You can't get it
<chaals-ordhord> Ben: Does fetch require secure context?
wanderview: you can create a fake request with a http url, but [...]
<chaals-ordhord> Surma: no, you can fetch http:
<chaals-ordhord> MK: You can postMessage a response as a hack.
Mek: if you postmessage the response you would be able to get a http response
yhirano__: it's possible to [..]?
JakeA: not via Fetch
... if you call event.respondwith(event.fetch) it will fail due to mixed content
<chaals-ordhord> JA: we're fine with what browsers do now.
<chaals-ordhord> YL: what happens with an upgrade insecure request?
yhirano__: thought that was transparent
<chaals-ordhord> Ben: doesn't happen before the request
JakeA: step four of mainfetch
<chaals-ordhord> Ben: I will write some tests for that
wanderview: we should have tests for that, not sure of the implementations
<JakeA> https://github.com/w3c/ServiceWorker/issues/1075
<chaals-ordhord> JA: might have covered yesterday
<chaals-ordhord> ... Anne says he will get to it next week. seems fine.
Domenic: does anyone interested in the actual parse issue?
<chaals-ordhord> DD: Actual issue. If you're a popular site you often convince people to copy/paste an iframe snippet.
<chaals-ordhord> ... now you can use ancestor origins to see where a user saw those embeds. So provide a way for sites to opt out of that.
Domenic: via ancestororigins you can see a list of all pages where your user can see your snippet
JakeA: iframes can already reach their parents?
<chaals-ordhord> DD: iframes cannot reach their parent window crossorigin for things like location
Domenic: not cross-origin
jungkees: annevk is concerned about frametype
<chaals-ordhord> JS: In previous f2f we concluded frametype isn't meaningful, Anne pointed that back.
<chaals-ordhord> JA: wait for Alex.
<chaals-ordhord> Ben: And usage data. If nobody removed it, we should note that.
JakeA: as usage numbers come back we could remove it
<JakeA> https://github.com/w3c/ServiceWorker/issues/1033
<chaals-ordhord> JA: Spec just had most commonly used MIME types. We should switch to the HTML definition
<chaals-ordhord> ... doesn't feel scary
n8s: makes things less surprising
<chaals-ordhord> DD: Saw someone real confused by this... not just spec theory
<slightlyoff> OMW over now; apologies (meetings)
<JakeA> https://github.com/w3c/ServiceWorker/issues/719
JakeA: we talked about this briefly
<chaals-ordhord> JA: attack is I can find urls of your fonts
<chaals-ordhord> ... and imports
<chaals-ordhord> ... but doesn't feel like a big deal
no getcomputedstyle, so no background images
<chaals-ordhord> DD: tingles for me in combination with another attack
<chaals-ordhord> JA: Yahoo mail attack, right?
JakeA: is this like the yahoo mail attack?
<chaals-ordhord> ... construct a background image they could get.
<chaals-ordhord> Ben: SHouldn't leak cross-origin info except CORS
wanderview: on the one hand we shouldn't be leaking cross-origin info
<chaals-ordhord> ... Jonas argued that stylesheets are already so leaky this isn't a big deal
Mek: we don't have opaque requests--only opaque responses
<chaals-ordhord> MK: Request shows URL, only response is opaque.
<Domenic> https://www.linshunghuang.com/papers/css.pdf
<chaals-ordhord> DD: Oh, someone has an attack described
Domenic: someone has an attack that seems very similar
JakeA: does it treat a non-css resource as css?
Domenic: [yes]
wanderview: chrome should lead the way on this change due to having been released
<chaals-ordhord> Jake: I like the idea of abdicating responsibility... ;)
wanderview: I don't have strong position, in the end I'm willing to implement what the group decides
<chaals-ordhord> DD: Suspect few people load x-origin resource in styles via SW
wanderview: I think [there are a lot of unspecced issues]
<chaals-ordhord> JA: COunter - if you cache a google font.
<chaals-ordhord> DD: Hmm, maybe. Or maybe we can break them on people and live with it
<chaals-ordhord> JA: For an icon font that's bad.
<chaals-ordhord> KB: If it doesn't work you can reload and get your font.
falken: there's an open CRBug, and sec team is pinging us on it
wanderview: we had a restricted bug and since it was on github, we unrestricted it
Domenic: I'd really want to fix this
... someone will string this together with other ones, it's a sec issue waiting to hppen
<falken> (the restricted crbug is 532374)
Domenic JakeA: we need to look at the attacks
Domenic: from just skimming the attacks, it pushes me to fix this
<kbx> DD: we sometimes do break fonts, like the 2G intervention. (context for KB's comment; on 2G Chrome doesn't block on fonts, it still does an async download though for subsequent nav/visits)
<chaals-ordhord> Ben: We should try to resolve this not f2f
wanderview: let's try to resolve this async
... get the right people into "the room"
Domenic: ask people, look at the use counters
wanderview: there was an other issue we resolved
... are you still doing it?
... I'm willing to implement it
falken: we haven't yet, but yes we are planning to
wanderview: [finalURL]
... it would strengthen our sec infrastructure
... adds to cross-origin protections
<kbx> maybe this issue: https://github.com/w3c/ServiceWorker/issues/787
falken: I think we ended up with the same, that it would improve security so we want it
<chaals-ordhord> JA: Don't need to do that f2f, no behaviour changes.
<JakeA> https://github.com/w3c/ServiceWorker/issues/1040
wanderview: people were polyfilling bg-sync by creating new extendable events
... in hopes that it was going to be able to extend lifetime indefinitely
... I'm okay with having this extend to the allotted time budget
... or just say that manually constructed extendableevents have no associated time budget
JakeA: would speccing time budgets fix this?
<chaals-ordhord> TOC: so user-constructed events don't grant any more time?
<chaals-ordhord> JA: right
<chaals-ordhord> TOC: what about synthetic click from a page?
<chaals-ordhord> JA: you could do a postMessage to grant time.
<chaals-ordhord> TOC: SW cannot grant time to itself, as meta principle.
<chaals-ordhord> JA: right
wanderview: if we would have this on global time budget, one could have this time borrowed from any "disconnected code"
<chaals-ordhord> Surma: why expose constructor anyway?
<chaals-ordhord> n8s: so you can pass events to yourself.
wanderview: if we wanted it to have time one would have to pass in the original event (that had time budget associated)
n8s: [agrees]
<chaals-ordhord> [jake scribbles into the issue as we chat]
falken: in our implementation it would be hard to plumb these over to the main browser process
wanderview: in our code I just set extendable false for manually constructed events
Mek: there aren't any flag like that on spec!
wanderview: ah this is from before the async waitUntil stuff
<chaals-ordhord> JA: We'll figure out the spec-ese async/later
<JakeA> Next topic: Where are we in regard to multiple service worker threads? Also: what's going on with shared worker?
*multiple instances of
<chaals-ordhord> TOC: we'd like it. is there a compat problem?
<chaals-ordhord> JA: Think so
<chaals-ordhord> n8s: seems like the bridge is burnt.
<chaals-ordhord> AR: Would support an opt-in given evidence we need it
<chaals-ordhord> JA: Is it for performance or ease of implementation?
<chaals-ordhord> TOC: Both.
<chaals-ordhord> JA: So opt-in for ease of implementation isn't going to help
JakeA: you can just treat global scope optimistically
pieter: but then if we want to rely on data we need to go to indexdb and it might stop being a perf win
<falken> i think the issue is https://github.com/w3c/ServiceWorker/issues/756
JakeA slightlyoff: having data on this would help us understand better how to prioritize
slightlyoff: we'd get data from fb right?
n8s: yes
slightlyoff Domenic: it might be hard to implement, not sure it's worthy of experimenting until we have data on (potential) benefits
wanderview: instrumenting service workers could come as a benefit from this
asuth: do we have data on SW js size?
falken: yes--but it would probably be all facebook :)
wanderview: for foreign fetch we might want to do this
JakeA: yes and foreign fetch might be a good way for testing this
wanderview: we could just do this with separate globals, but potentially same/different thread
JakeA: wouldn't that be slower?
wanderview: this is not a perf suggestion
... but then one could just use a threadpool to spicen it up
... not advocating for it, just saying it could have other benefits from this besides perf
tess brady: would even make this a default for foreign fetch
JakeA: so creating a realm...
tess: that's fine they're cheap
jake tess: we could do up to realm abstraction
ali: can we talk bg sync as well
... it runs in a separate process
brady: our indexdb is in separate process as well
n8s: for us, as long as all push events went to the same sw it would be ok
... our sw had to be able to msg clients
ali: usecase?
n8s: we have a throttled client that we want to notify from sw, to update badge count
... we don't need global state in general, but clicks and pushes should go to the same sw
ali: we could guarantee the click, but not sure about push
... there are edge cases, related to running the background sync in a separate bg task
... the bg task makes sw a "good citizen", advantages come from the os standpoint
... but there is a "drawback" related to having to have it in a separate process
tess: I don't see as a drawback
... does it coalesce payloads?
ali: don't think it does
... facebook knows what end point it wants to push to, but I don't think all devs will be that sofisticated and will need help from os level
JakeA: this all sounds like a good first step
ali: our goal is to be able to scale this to multiple sw, multiple fetches go to separate sw
... we're not there yet but the goal is to be able to do that
... my guess is for mobile we'll keep this at 1 sw, but maybe higher-end devices could do higher
asuth: would it worth to expose in an installing worker what will they be doing (e.g. sw-s specifically for push)
n8s: don't think we want to spec that
wanderview: one could spin up different sw like that
... do we wait until ms tries this?
slightlyoff: want to see data first
ali: even data aside we think it's the better approach
n8s: def agree for push
ali: and bg sync
tess: [agrees]
ali: f12 is gonna be tricky
... can't debug the sw that's not inside of edge
n8s: can the sw see each other?
slightlyoff: they can see the client, so can get a messageport through
wanderview: question is what a service worker dom object represents?
... is it an istance, a potential instance?
tess: you kill them all the time anyway
wanderview: we could have the sw dom have a getInstances()
... then get a list, postmessage the first one
n8s: which is the first one?
slightlyoff: in ms case you just don't let the two sw run at the same time
the os process service worker just has chakra, network stack etc
n8s: why does the sw have to live in edge in the first place?
ali: we thought about that, but it isn't
... the bg service worker is running in a process we don't own (in a bg service infrastructure)
... we want to own some stuff about our service worker process
... we are the first impl to try to do this (running in a bg thread), and it will certainly open a sort of pandora's box
... not having global state and postmessage is the two problem areas we have identified
n8s: postmessage is a problem, replying to (the correct) service worker might not be possible due to navigation and global state might have changed
asuth: would shared workers be still possible?
ali: we are not looking at shared workers right now, but I cannot answer now
JakeA: you could use broadcastchannel, have the service worker with an active push event respond?
n8s: yes but that's quite messy
ali: do you use a messagechannel?
n8s: we do
ali: who sets it up?
n8s: currently it's the sw, but could see it work the other way around
[discussion over M tabs and N service workers becoming a distributed system, and hard to find way to make interactions easier]
you can just channel your push messages through the running sw
ali: you cannot trigger the bg service worker thread, it is only triggered by the os as a result of a push
slightlyoff: it's a policy question of handling half-delivered events
... on android you could already have processes killed any time
... i don't think we redeliver now but you could
ali: then you don't know if your half-delivered event is idempotent, might potentially redeliver events
tess: it's not ideal
ali: it definitely isn't
slightlyoff: a push daemon starts chrome itself, with special cmdline flags that don't create a window early on
... we currently killed our windows system service, it wasn't very good
... it was effectively running chrome in the background (our profile service, but that starts up most of chrome)
... we are trying to atomize chrome and bring it back again
<JakeA> https://github.com/w3c/ServiceWorker/issues/1077
n8s: self.self? :)
<JakeA> https://github.com/w3c/ServiceWorker/issues/1076
n8s: [self.]serviceworker
[agreement, bikeshed further on name]
<JakeA> https://github.com/w3c/ServiceWorker/issues/1016
JakeA: often ppl just postmessaging into a serviceworker just to have it skipWaiting - why not expose this on the page?
n8s: I could see it come easy, if it isn't too hard to impl
wanderview: we shouldn't create reasons for ppl to postmessage
falken: should it go on the sw or the registration?
JakeA: service worker?
wanderview: better to be explicit
<JakeA> https://github.com/w3c/ServiceWorker/issues/842
JakeA: expose install time?
wanderview: don't see a reason why not?
n8s: feels like an id...
... I don't think it's useful as a timestamp, as opposed to an id
... ppl will just do bad things with it
wanderview: maybe have this display the last update check?
asuth: wait for more complaints?
n8s: yeah
asuth: we're gonna expose in devtools anyway
... "my sw is not installing -- check its timestamp!"
<JakeA> https://github.com/whatwg/html/issues/151
wanderview: wontfix it and come back later if needed
JakeA: disable it on http?
... maybe chrome should take a lead...
wanderview: how about the polyfill?
JakeA: haven't looked into that thoroughly but it's probably not right
flaki: maybe the appcache polyfill doesn't help with complicated setups
slightlyoff: we run one of the most complicated caching logics, deprecating and removing appcache would make it easier for us to transition more properties
... we are currently hamstrung by it
JakeA: appcache is not like mega-complicated -- it's just wrong
falken: for internal sites, it's mostly perf regressions, not the lack of willingness
JakeA: proposal to have a polyfill function that takes a manifest file and serves files according to it from inside the service worker
Domenic: what happens if you have both?
JakeA: handwavy, but tldr is: ignore appcache
wanderview: it doesn't make a lot of sense for annevk to integrate appcache into fetch
slightlyoff: what is the process of removing features?
Domenic: we generally keep them until they're gone from at least two browsers
JakeA: removing from http, what does safari thing?
brady: not an objectionable idea
<chaals-ordhord> FWIW https://github.com/w3c/html/issues/40 was closed and in HTML 5.1 appcache is in an appendix of stuff browsers need to know but authors shouldn't touch
aliams: unfortunately we have enterprise users, so it's gonna take some time...
... at some point we can say they should just use IE
... we're not gonna do it before we ship another solution...
JakeA: but you're not gonna have sw on http!
<slightlyoff> crbug: https://bugs.chromium.org/p/chromium/issues/detail?id=588931
<slightlyoff> sadly the engineer who added this left the team
<slightlyoff> I'll try to find a new owner
flaki: also on bugzilla: who is it gonna break, and how badly, on unmaintained sites if we remove it
JakeA: you can hack news permanently on sites!
n8s: this removes all the trust
salva: we are talking about removing a well-established feature
yves chaals-ordhord: question is, should we do more work to improve it or just let it die when sw becomes prevalent across the platform
JakeA: I _want_ to yank this from http
[?]: I want me to find a way
Domenic: what would happen if this actually became an easy to use attack?
wanderview: can we badge this terribly visibly?
... the user cares more about this, they could exert pressure on the developer
... at least our experience with password field was successful in getting sites to switch
JakeA: altohough opening in other browser, one that does not say "this site is compromised"
chaals: ppl do and switch browsers
Domenic: anecdotal security experiences shouldn't guide our decisions
JakeA: kill it with fire!
wanderview: non-throwing fire
JakeA: soft-fire
wanderview: should put "annevk will do all this work"
JakeA: allready done. :)
<JakeA> https://github.com/w3c/ServiceWorker/issues/920
JakeA: this is a feature chrome wants to ship pretty soon-ish
n8s: we are seeing improvements but that doesn't mean we're gonna see noticable improvements in stable
JakeA: we are waiting for more data from FB then?
n8s: we _are_ definitely seeing improvements, but nonconclusive
... I think the API is in a good shape
JakeA: feedback we got falken ?
falken: they see preload response as a perf thing and not something one wants to use on every navigation
... issue preload resolving to undefined, partner needs guarantees against that
... proposal of parner: browser should automatically use preload response if there was no respondwith
n8s: sounds too confusing, partner should just build it in their sw
... the preload response header will be set anyway
slightlyoff: partner is very concerned about reliability, so they want to funnel as few events through it as possible
wanderview: great to have fb and other real-world use cases
asuth: what is the usecase?
slightlyoff: they are using a sw for just logging, but proxying things through the sw and makes things slower (albeit having no actual logic in yet)
[..]: ?
n8s: pre-tpac we debated a lot and decided it was more confusing
pieter: we're confident we have mitigated issues in a sufficient depth that they become just normal "bugs"
falken: other implementors?
wanderview: still doing the rearch, we don't have objections
<kbx> KB: ideally, they would want to opt-in nav preload but only to mitigate cold startup issues. Disable when receiving the first preload response and re-enable before the SW dies.
<kbx> => 13:46 [..]: ?
JakeA: facebook would still work without this feature right?
n8s: yes but we don't want to roll out a perf regression
ali: at some point it will come, would be happy to see it
brady: no strong opinions
<JakeA> https://github.com/w3c/ServiceWorker/issues/1000
OK
Mek: origin trial
... not too much usage, but measured _some_ usage...
JakeA: facebook was looking at this?
n8s: I don't recall
... it looks interesting, probably be good for plugins and such but not there yet
... we're definitely interested on the long term, but not on the short term
<falken> ( kbx is speaking)
kbx: fonts usecase is still strong
... they want to store "pings" on the local service worker, and ping it back to the server in the background
... that one would need some kind of "timed alarm" which is not available currently
[discussion on timed alarm]
kbx: usecase: doing one's own stale-while-revalidate, making sure one's script in the head never blocks
... usecase: trying to get something from the network, that takes too long, serving a fallback response after the timeout
<JakeA> https://github.com/w3c/ServiceWorker/issues/878
JakeA: site can turn on credentials for some requests
[discussion that the functionality is not a Super Cookie as it is deleted when requested from the user, since the service worker obeys that]
[discussion on having double-keying's impacts]
wanderview: apple wants to put this off and rethink it
... I don't think it's reasonable to put this off untill all browsers out there support double keying
... since foreign fetch is a progressive enhancement, so it might not always be there
JakeA: so apple won't be able to ship it?
wanderview: or ship it and be less effective, and that's fine
Mek: it's already disabled if one disables 3rd party cookies in chrome
slightlyoff: this was raised by mozilla
<slightlyoff> (more to the point, we propose navigator.connect() and the reason we're here is because Mozilla requested an API of this style instead)
wanderview: I'm not trying to abdicate responsibility, but chrome has put way more effort into it and has more skin in the game
... I'm just concerned about tracking
... I have proposed static routing to solve the SW usecase
Mek: but it doesn't solve the font usecase
... e.g. subsets of fonts
wanderview: we didn't know about this usecase
[..]
slightlyoff: we're probably gonna have resource-usage based limit
wanderview: having a separate Realm would help in this case
... allow the realm 1 or N fetches
Domenic: navigator.connect had the same issues...
Mek: that was opt-in from the intercepted site
JakeA: but this is opt-in from the site itself
... says "I trust this site not building a botnet"
Domenic: it's worth exploring opt in, csp, maybe opt-out - let's just give annevk/apple time to come up with a better or alternate solution
tess: noone is shipping this (yet) so we are not in a hurry
slightlyoff: we _do_ want to ship this at some point though so a decision would be great
JakeA: we'd still want to have an origin trial?
falken: what data are we missing from the previous one?
kbx: nothing..?
JakeA: I got the impression we didn't get conclusive feedback
kbx: we got, from ~80%
... the google fonts team couldn't get the perf metrics since it was unaccessible in the service worker context
salva: [..]
... one shouldn't be able to reduce the security of the incoming request
slightlyoff: is that an existing issue?
wanderview: it's part of it
[chrome team argues the problem still applies in any case?]
wanderview: having a separate realm enables more ways of mitigation?
kbx: [..]
JakeA: and the opt-in helps there
Domenic: it's not just webfonts, but "make webfonts faster across the board"
tess: [..]
slightlyoff: and it's terrible, really really slow
kbx: to be fair it's gotten better
<slightlyoff> (it has gotten better)
asuth: one doesn't want images
JakeA: but css signals clear intent
slightlyoff: do we still filter images?
surma: [..]
Domenic: we should fix this
asuth: is there a navigator.connect post-mortem?
Domenic: we had a cool idea -- Mozilla said: we have a better idea -- domenic: "well it is kinda better"
JakeA: do we want to start whitelisting types?
Domenic: annevk has been collected a list, if we do want to do it it seems doable
<Domenic> In particular: https://fetch.spec.whatwg.org/#concept-request-destination
JakeA: so are we at the opt-in and enumerating type
wanderview: we have multiple issues, with multiple solutions, talking about them at the same time is confusing
Domenic: this would benefit from offline (as in async, gh-back-and-forth etc) brainstorming
wanderview: who is going to organize the follow-up discussion?
... it's complicated enough so we need to drive it forward
<JakeA> https://github.com/w3c/ServiceWorker/issues/877
tess: currently is pretty ambiuous why a sw is killed, how about exposing this data to the client?
Mek: we have discussed during background sync some "you were timed out event"
JakeA: like next time you boot up?
tess: yes
Domenic: this sounds like the "long tasks reporting" I'm working on
... it fits wit recent platform trends
tess: it's rather coarse, but it could be useful to share things
slightlyoff: navigation error reporting sounds similar and appears on the perf timeline
<slightlyoff> here's the latest NEL: http://wicg.github.io/network-error-logging/
slightlyoff: maybe we should use the NEL error header?
JakeA: some coalesced api would be nice
kbx: it's not just for navigation only
<Mek__> http://wicg.github.io/reporting/ is the generic reporting API
Domenic: action item: [figure out the contact points?]
wanderview: might be too much data?
<kbx> Contact points for Reporting API: Ilya Grigorik and Mike West
tess: no need to retain too much of this
n8s: it's pretty hard to debug or notice even
... it's definitely bit of a blind spot
asuth: should we have like histograms: you lasted this long and died of (memory usage|cpu usage|etc)
... also maybe report to browser vendors
... have it as an opt-in
n8s: sounds like we all agree we should address this blinds spot--question is how?
... one can end up in a feedback loop
flaki: maybe more declarative, during registration
slightlyoff: or a header
Mek: e.g. via the reporting api?
n8s: navigation timing is kinda an odd fit
JakeA: there was an error reported for update failures
... changed url
wanderview: not just that but mime type failures and etc
n8s: we do this intentionally often
wanderview: why?
n8s: sometimes we want to keep old sw version, and don't care about it when it happens intentionally
... you can catch all rejections inside the sw
Mek: you wouldn't have much time
n8s: 30s should be enough
asuth: one could just throw an AbortError if not interested in submitting the error
wanderview: we have gotten reports of people wanting to know more about this
kbx: one might need more access which only client-side processing could provide
<JakeA> https://github.com/w3c/ServiceWorker/issues/939#issuecomment-240135914
wanderview: with a perfectly-written sw this wouldn't happen but when someone pushes a bad service worker...
JakeA: coming up!
... suggestion from a chrome eng: an event that fires on the service worker when the page displays an error
n8s: we love the idea
... we have made a polyfill, using indexdb pinging the service worker that can get us an approximation of this data
... the data is not perfect but already pretty useful
pieter: normally we have to wait until ppl tell us the page is crashing
falken: the client goes away at this point...
n8s: yes first step is to get the info, but then potentially try to recover
Mek: automatic recovery might be not desirable here
n8s: showing some ui, e.g. "try to recover" button could be helpful though
JakeA: the refresh button is always there
n8s: maybe we want a spinner that would wait for the sw to try to recover
pieter: the developer cannot be sure it won't crash again
n8s: probably browsers should only offer recovery once
wanderview: in firefox, multiple tabs run in a single process, so it might have been an another tab that caused the actual crash
slightlyoff: for sites that's as big as fb this should not be an issue
wanderview: more talking about the recovery
... that said, this might be possible but after the rearchitecture
n8s: sure
JakeA: does 404 etc. error pages count here?
n8s: crashes are more interesting to us in this case
JakeA: if we do, we should provide appropriate context
slightlyoff: updating {title|favicon|etc} from the service worker (upon push/bg sync)
JakeA: why not just postmessage?
slightlyoff: resource usage gains, eg tab should remain in a dozing state (maybe put to disk etc)
Domenic: is this just for desktop?
JakeA: sometimes this works on android, e.g. a custom app icon
n8s: most non-Google android has it
... there's also an issue of updating the title, but then upon tab switch the content not having been updated
... (do to postmessage being queued still etc..)
Domenic: do we do mobile/desktop together?
JakeA: they're different enough, on mobile we have "apps" on desktop we have "tabs"
slightlyoff: I'm happy to write something up
flaki: maybe we could have like a method that updates "page metadata" with an object with different keys
Domenic: we have to decide if this is appwide or tabwide
n8s: this could just live on the Clients API
brady: we are in, we want to see a spec
... we are also not interested in any scriptable ways to update in favicon
slightlyoff: would providing a "badge count" be okay?
<JakeA> https://github.com/w3c/ServiceWorker/issues/1087#issuecomment-290705968
tess: we have a badge count api so that should work
JakeA: what's the issue with favicons?
<hober> https://notifications.spec.whatwg.org/#badge-url
brady apple doesn't support any updates to the favicon
Domenic: not even data url hacks?
brady: nope
<JakeA> https://github.com/w3c/ServiceWorker/issues/614
wanderview: we even have a test in-between testruns that fails immediately if we have any service worker registered on any origin
Mek: maybe update web platform test harness to have async cleanup callbacks where you wait for their promise to resolve before moving on to the next test
falken: test harness already lets one access chrome-internal functions
[discussion on event.waitUntil and being able to rely on the service worker not being killed of for "a reasonable amount of time"]
JakeA: the spec is vague and we need to address this when we do time handling and passing around
<JakeA> https://github.com/w3c/ServiceWorker/issues/839
tess: we need guarantees both for "you got to be executing for at least this long" and both "you will be definitely killed of if you keep executing beyond..."
wanderview: wrote and reviewed patches, should land in 55 ideally
falken: currently we cache by default
JakeA: are we going to melt facebook?
falken: not facebook. any other sites?
... we don't have the exact data to know
... it's also hard to know the exact sites (for evang), if they in fact melt
kbx: we could try a phased roll out (for canary maybe) to make sure we don't break things
JakeA: next meeting?
... maybe better to have at least one more focused/teleconference?
wanderview: maybe it's better to not phrase it around "n times a year" but shipping (e.g. after Edge ships?)
JakeA: we might have mkwst at TPAC again?
wanderview: we're at a point where before implementing new platform stuff we write wpt
[agreement]
wanderview: we don't need to be at a big-bang meeting
JakeA: how about august?
tess: first week of august is CSSWG
<falken> (wanderview was responding to a suggestion about holding a meeting focused on WPT)
ali: we should address these issues online (and prepare for the meeting)
JakeA: we might need a meeting where we organize meetings! \o/
... V1 status?
jungkees: slowly toiling away on issues, but also we're gonna file some after today
... if we want them to get resolved before shipping we either need to push them out or split them out
ali: we are tracking V1
... it might be worth to split stuff out (that's contentious, in origin trial etc)
JakeA: I'm worried about locking V1 down
... what if what ships turns out not to be in a good shape
slightlyoff: V1 is what eventually will ship
JakeA: I'd rather freeze V1 and have it at whatever ships eventually
JakeA: we're moving onto a more modular world, we should spend more time on this
slightlyoff: getting the top-level script fixed is *good*
JakeA agrees
wanderview: usecache equals import default?
JakeA: like the idea
... the declarative imports will be checked on first launch, and will be checked on updates
Domenic: it sounds strange from a module standpoint, but you already do this for importScripts
JakeA: is usecache the right language?
... this is more about rechecking the script resources
wanderview: my take is we always include importScripts in the byte-for-byte check but we use the cache
... we hope to ship our usecache impl in the following weeks
... but I want to shift that boolean into an enum before we ship (maybe could even uplift)
... this is for toplevel
... we need to agree on what the default value should be
JakeA: n8s (representative of ALL developers around the world), what do you think??
n8s: fine.
JakeA: \\\o///
falken: should we think about es6 modules when we design usecache?
Domenic: yes, it would be advisable -- happy to coordinate
wanderview: we're gonna have different policies on toplevel script and dependent scripts
salva: and check for headers
wanderview: it's a revalidation, that uses eTags
JakeA: yes it's a "nocache" request (on cache api's terms)
wanderview: we probably won't ship our bypass cache in 53
JakeA: yes it was a late thing
... library authors will need to be setting the header...
Mek: they get the byte-for-byte check by default anyway
JakeA: true
Domenic: want to talk about cacheable resources
<JakeA> https://github.com/w3c/ServiceWorker/issues/962
Domenic: implementations event with service worker differ in implementation
*even
Domenic: we have to somehow tackle the cache thing
JakeA: are you suggesting us speccing a handwavy "browsers may..."
Domenic: could do that, but also could just spec it
yhirano__: I think is nothing specified we should use http cache semantics
slightlyoff: memory cache doesn't respect caching headers, because we found we want to very much cache these resources
surma: compared different scenarios, bold means "the average developer would be surprised by this"
... it's very hard to predict what happens when doesn't have this table at hand
Domenic: it's a mess
... how does it impact service workers?
JakeA: wanderview said firefox would go to the memory cache
... but that's not specced
wanderview: yes our impl does not comply spec and reuse images from across documents
... these optimizations gave order-of-magnitude improvements
... we could just use headers, and SW would put headers on the responses
slightlyoff: what do we doe in chrome?
... is it disabled?
falken: not disabled, but we use a different memory cache for pages using serviceworkers
yhirano__: but it's also nonspecced behavior
wanderview: allowing the service worker participating in higher level caches is one effort, laying the specwork could be a different effort
Domenic: laying these on such a shaky foundation doesn't feel right...
... ...but also I don't see terrible compat risks here either
... it's little surprising that we are not fixing all issues first
wanderview: it's more "separation of concerns", rather
Domenic: we're exposing unspecced/nonstandard behavior to service workers, but before we exposed this to the http service
wanderview: we fixed our image caches because someone complained about the surprising behavior
... "I should be receiving a fetch--and I'm not"
Domenic: how come we are not seeing more complaints about other caches..?
JakeA: developers don't really understand caches in depth
kenjibaheux: well we never talked about client-side caches, mostly just server-side (re: headers etc)
wanderview: if the service worker updates one should evict all those caches
Domenic: behavior should get specced soon(tm)
JakeA: our designated developer..?
chaals: not designated, but representing ALL developers in the world
n8s: *nods*
wanderview: bfcache..?
flaki: do we need to expose b/f cache to the service worker?
wanderview: one could opt out via the same, to-be-specced mechanism
JakeA: we need to look at these
wanderview: if we could turn image caches back on that would be great
JakeA: last requests?
Domenic: [fixing top-level events after initial evaluation?]
JakeA: yes we should look into that.
... Thanks Facebook for hosting. Thank you all for showing up.
<chaals-ordhord> [Thanks to Nate/Peter/Kate and Facebook for hosting, thanks to Flaki for notetaking]
*fin*