Serviceworker f2f

03 Apr 2017


chaals, Yves, JakeA, AlexR, Jungkee, catalinb, Flaki, horo_, tyoshino, yhirano__, asuth, falken, Makoto, Kinuko, wanderview, Surma, Google, Mek, jungkees, Ali_Alabbas, MikeTM, DomenicD, tess, bradyE, Salva


<tyoshino> Good morning

We can start looking at the Client APIs, as most of that is clarifications anyhow (JakeA)

<JakeA> https://github.com/w3c/ServiceWorker/issues/1093

issue 1093

Ben: we're rearchitecting clients stuff

jungkees: spec and implementations do not really agree on environment
... in gecko there aren't any object to hold this data

wanderview: we have a patch pending
... pending patch, we do have the concept for when a navigation becomes a client NSILoadInfo

jungkees: maybe do what chrome does [] copy all the states
... replacement case is the tricky one
... do you intend to expose the reserved client to the initial document on window

wanderview: question is where things get reused or created scratch
... e.g. on iframes, when one sets src attribute

jungkees: the initial window/browser context was there and just navigate somewhere else - will there be two objects?

wanderview: navigation will create a new innerwindow

jungkees: we'll have two client ids?

wanderview: one client id but the url changes on it
... a navigation is different than a replacement, a new environment is created

jungkees: with the initial document there won't be a window created

JakeA: a developer can see this reserved client come in and assign a new cache to it and continue to serve it from the cache - if we change it, this usecase is broken

wanderview: if the redirect is same-origin keep the client, otherwise throw away

JakeA: you get a reserved client, but it's id changes due to redirect

slightlyoff: it's cross-origin, goes to a different sw

wanderview: [...] I think it should be okay - if I implement could be a weird corner case...
... I have a bunch of clients issues
... we supposed to inherit the SW via iframes' inherited origins, the scoping logic doesn't match
... claim doesn't say anything about claiming children with inherited origin

JakeA: [..]

wanderview: you could put things on one document or another.

JakeA: if you move it over to a different service worker would you expect all controllerchange etc. events to fire?

wanderview: is that implemented yet in Chrome?

<falken> (the person in the green is falken)

falken: not yet

<jungkees> https://github.com/whatwg/html/pull/2080

jungkees: this is about iframes' controller inheritence from an earlier pull request where we sort this out
... src initial blank document case automatically gets their parents' controller, but then it goes through matching (matching always wins)
... one corner case [..] it won't match anything so we fetch the controller from the parent again
... I wrote up a wp testcase, but it didn't land yet due to travis issues
... could implement later when we have the expected behavior
... does this cover the claiming case?

<falken> see also https://github.com/w3c/ServiceWorker/issues/612

jungkees: yes

<JakeA> (Mek__ is speaking)

wanderview: if you have a blob url worker, it should be controlled by the same controller

Mek__: blob url is even more complicated which controller would it use?

wanderview: you mean the blob url could be passed from diff document

Mek__: modules' workers are cross-origin [?]

wanderview: just add id as a holistic case for future

falken: we had an issue like this earlier
... it's probably better to unify the specs

jungkees: now we are speccing it in html

<falken> (the issue earlier is https://github.com/w3c/ServiceWorker/issues/612)

wanderview: I thought there was spec parts for the iframe case

<JakeA> https://github.com/w3c/ServiceWorker/issues/1091

wanderview: the issue I ran into while implementing (it's probably bugs)
... when window created it's execution ready, once navigation complete [..]
... if you inherit a controller when it loads, you drop the inherited controller?
... maybe we do want to separate clients...
... I don't know all the places where replacement is triggered

slightlyoff: you replaced the document but you haven't done anything to the exec context, its the same
... if I'm controlling one tab ...

JakeA: if I'm trying to recreate appcache
... if you are navigating a single frame around...
... during navigation you have a reserved client (might not happen, download/fail)
... if it does happen it goes away

slightlyoff: just feels much easier to just create an event on the client object

JakeA: we shouldn't be mixing state in

slightlyoff: what is this for?

JakeA: to give away more info on the client (what started it, what's it become, what will be replaced)
... pushState doesn't create a client

slightlyoff: maybe too late to change all of these

JakeA: don't see what benefit it would have

slightlyoff: I have a client, generate a reserve client (through clicking a link - navigation).
... what was the previous state, future state. at the future point in time you want to determine what happens, sounds like events to me

JakeA: I clicked a link and what do you want

slightlyoff: what can I do? postMessage?

JakeA: yes

wanderview: if it redirects cross-origin the client is gc/d

slightlyoff: you might not want to change the policy there
... let's move on, too late to change

<JakeA> https://github.com/w3c/ServiceWorker/issues/1038

wanderview: environment settings helps (b/f cache), we just restore that exact client
... b/c cache, env settings - I'm maintining in-memory the inner window, mark it inactive, and if you go back we just restore it
... it has the same client id
... it would be great to have control/uncontrol events fire

Mek__: what happens if an update happens?
... are updates blocked?

wanderview: no

Mek__: what happens?

wanderview: good Q

JakeA: does Edge have a B/F-cache

aliams: no

jungkees: it would make sense to attach the sw again
... we need to see if it specced in HTML\

<falken> (aliams said yes there there is a form of b/f cache that keeps pages out of view. no it doesn't reparse/rerun js when returning to a page in the cache)

wanderview: what we don't want is 10 history entries to keep a sw from updating
... we already have this exception for the reserveclient

salva: users aren´t aware of b-f cache, so maybe you should not deliver messages to this client

wanderview: when someone navigates that message gets lost, when it comes back the app could be in an inconsistent state
... if the client has settimeout(0) before navigating, then goes back, that timeout will execute

JakeA: on Window [..]

wanderview: or use promises that reject but that would be very-non-postmessage-y

asuth: in broadcast channel when you try to communicate with the page in the b/f cache, it kills the page

JakeA: isn't that weird?
... you kill the page upon intent of communicating with it.

asuth: not too weird because the page can't respond in a timely manner since it's in the bf cache

wanderview: odds are, people are not going to go back to the page

slightlyoff: do you have data on that?

wanderview: not currently

JakeA: if you attempt to communicate, and it's not gonna be able to respond in timely fashion, it makes sense to make it so it's not there == kill the page

<chaals-ordhord> [cmn note to self, the s/ above will need to be tweaked because it has a / in the middle]

wanderview: is this also applies suspend/freezing bg documents

JakeA: yes
... openwindow can reuse one of the dead tabs

<aliams> https://msdn.microsoft.com/library/dn265017(v=vs.85).aspx

JakeA: it gets complicated if the tab is not merely dead--it's just resting!


JakeA: potentially in edge if the page has a s/w bf-cache is disabled

aliams: we have other exclusions, like for HTTPS (for sec reasons)
... so they don't have it anyway

JakeA: firefox is trailblazing b/fcache then?

wanderview: safari has it afaik

<JakeA> hober: Safari has a bfcache - have you any thoughts about this & service workers, especially in terms of client lifecycle?

slightlyoff: any more info on the HTTPS reasons? firefox might take note?

<JakeA> hober: We can hopefully discuss later

asuth: firefox used to be more strict about it, but we relaxed that since, it's just transport security no deeper meaning

<tyoshino> kinuko said

<JakeA> hober: Is there a doc on the cases where Safari will avoid bfcache?

<falken> kinuko said AFAIR safari disables bf cache on https if the resource is mapped as no-store

<chaals-ordhord> kinuko: Safari avoids it in the case where you have https and no-show [??]

<kinuko> no-show -> no-store

JakeA: the idea that sounded ridiculous will be it, we evict?

wanderview: yes

Mek__: if anyone calls claim on the origin and that would change the active SW one would evict all

<kbx> Catching up here. Apologies for not being among you. If the topic is about interaction of SW and Back/Forward navigation. We got partners who would like the benefits of the fast back/forward nav despite SW. in other words, a way to opt-out or mitigate/avoid the SW latencies.

<kbx> kbx = Kenji Baheux

slightlyoff: are the considering adding b/f cache?

Mek__: yes

kinuko: we had it

slightlyoff: in ~2010

<kinuko> kinuko: we had it but only behind a flag, never enabled it by default

catalinb: should we have a special case [..] re: workers

JakeA: a shared worker should shut down

<kbx> Even today, SW appears to be slower than Chrome's load-prefering-cache.

wanderview: it's probably busted on b/f cache currently, but it should detach and re-attach

<JakeA> n8s: Are you on your way to collect Domenic?

wanderview: only the dedicated worker should control
... any child entity/child client should evict the top-level client from the bfcache

<falken> Chrome bug about bf cache: https://bugs.chromium.org/p/chromium/issues/detail?id=2879

wanderview: window.opener opens up a lot of weird edge cases

<JakeA> MikeSmith: are you also stuck downstairs?

<MikeSmith> JakeA, I got a number but am just waiting with Domenici, who doesn't have one yet

<JakeA> MikeSmith: cool. We're on it

<MikeSmith> super

<MikeSmith> smoker chaals now stuck down here too

<MikeSmith> apparently the badges are only good for one entrance

<MikeSmith> or something

<kbx> I learned my lesson. Tomorrow I'll show up on time :)

wanderview: retrospective from Firefox impl status


wanderview: in here we talk about common issues, but without having insight into each others' contexts
... it would be useful for vendors to discuss what's going on in their organization

<chaals-ordhord> Tess: Apple´s future plans: Apple doesn´t comment on future plans

theresa: I'll go first - apple does not comment on future plans

wanderview: if it's a breaking change we're gonnna let chrome do it
... [on slides] what we have implemented so far
... mostly implementing incremental improvements, not giant features
... we had Background sync close to landing for a long time, trying to land
... a lot of time is taken up fixing SW for multiple content processes (e10s shipping)
... which ties into why I'm curious about Clients api, use that for fixing stuff
... I have long-term architectural plans to use the Clients api and propagate the ideas throughout gecko
... the architectural overhaul may affect some in the future, just wanted to raise awareness
... [on slides] what we are planning
... we're not turning on ReadableStream until fetch event's getReadableStream()[?] lands
... we're trying to encourage our team to do more measurements
... not anticipating any big new features until rearch

aliams: sw landed behind a flag
... but we neutered it because a SW crashed some pages
... in the public build.
... the flag is off by default but turning it on doesn't do anything
... we have made immense progress since a year ago
... we're doing fetch abstraction, caches
... caches come out behind a flag in Creators update
... behind flag due to quota management issues
... we're moving away from our old quota management method, closer to the volume-based one Chrome/Firefox has
... Edge ships the OS and we have restrictions around that
... also moving indexdb under origin eviction in the future
... sw persists, still working on fetch interception and push
... push will work with the OS background system
... nice on battery etc.
... more complications on bg sync so pushing that out into the later future
... sw live in a separate content process
... other compromise: fetches have to be seen from the main process & sw, but we are not doing this for the initial release
... anything coming from e.g. cache api won't show up on content process (for now)

wanderview: manifest install?

aliams: yeah sure
... pwa story: filtered 1000-2000 sites that have SW+manifest
... we just inject them into the windows store
... "HWA" apps ~shortcuts to webapps
... specifically sandboxed, with real app identity
... claiming apps in the store will be possible (TBD)

wanderview: when will it ship?

aliams: we don't have to ship anything, can just reuse the HWA arch

n8s: readableStream?

aliams: working on it

Domenic: fetch body stream is already almost there

aliams: we hope to finish the fetch abstraction layer until the next release
... so by the time we have SW it will be easy(/easier)
... we have worked on our fetch abstraction
... we even fixed some bugs re XHR

falken: [on slides] what chrome team has been doing
... our main priority is performance
... we kinda' just stuck appcache and shared workers together, not really streamlined, so working on that
... we had an experiment to try to predict when one will need a sw
... we stopped that experiment (not very good results), not one of our priority
... finding fetch on the main-thread as a big bottleneck to pageload time
... we need the main thread for sw startup, we are trying rearchitecting the service worker to rely less on the main thread
... wpt tests are synced and are running on the commit queue
... you will see a lot of wpt commits, merging the chrome repository to wpt to get one unified test source
... the origin trial has ended on foreign fetch, we'll talk about this later
... uncovered & closed a loophole re foreign fetch
... more info from inside of the service worker, which was an earlier blind spot

JakeA: background fetch will ship in a few weeks hopefully, impl. by london team

falken: lot of "planned soon" stuff

<JakeA> Chrome is looking at making a request with a readable stream

takeshi: standardizing the process on fetch[?]

<JakeA> Adding readablebytestream

takeshi wanderview readablestream and readablebytestream are folded into the same type

Domenic: the evential goal is to have transformstreams
... last few weeks we were tweaking edge cases and got writableStreams into a good spot
... it's all coming together, hopefully streaming text, or even JSON decoding and other cool things are coming

takeshi: decoding stream is implemented behind a flag

wanderview: what about transferability

Domenic: we want to talk about it

wanderview: because of nested workers

Domenic: only firefox has those right?

wanderview: Edge too?

aliams: don't think we're supporting those in SW

wanderview: we don't either
... yet

Domenic: there are a lot of interesting usecases

wanderview: HT for the Chrome team on the WPT!

falken: the infrastracture was a great push for impl. aut sync

wanderview: implementing this is what, an hour, but the test is like a day - having the tests there helps a LOT

aliams: preventing the abuse of SW postmessaging?

Mek: we have a timeout in place for this

JakeA: one service worker kind of just "loans" time to other (service) workers

n8s: [on slides] facebook
... SW strategy beyond notifications: speed up page loads.
... since the last meeting a lot of time was spent on investigating perf

Domenic: streams are making everything faster!

n8s: weird results from testing
... when a sw turns on, faster to store on global

<kbx_> as in global scope?


"not crazy" - n8s

n8s: clone perf [?] is terrible[?]

wanderview: can we also have the data

n8s: ... yes
... [on slides] testing re: number of cores
... 2-core world is slow
... not even sw startup considered

pieter: for a small percentage of ppl its really fast but it goes really slow

<kbx_> re: keeping SW alive via postMessaging. Some use cases are motivated by startup concerns. Nav Preload should help mitigate the cold start cases given a significant RTT but probably not the warm cases. Should postMessaging followed by an actual fetch (within timeout window) be considered as a legit wake-up strategy (i.e. not penalized since the SW would have been woke up anyway).

n8s: in any of these measurements sw startup is not considered
... sw impacts non-cached content (when developer knows it is definitely not cached)
... having to wait for a full event loop turn is impacting video performance (since sw lives on main thread)
... if the sw doesn't respond, we don't just wait for the SW event loop turn, but then the main window event loop turn as well
... any kind of media requests

falken: sure it was the event loop?

<tyoshino> (takeshi: correction. decoding stream is not yet implemented. it's available as prolyfill at https://github.com/GoogleChrome/text-encode-transform-prollyfill)

pieter: some situations we're doing some heavy stuff on the client

wanderview: running js is always gonna be slower than not running js

n8s: we have been running this test for sometime, seeing small improvements

JakeA: without preload

n8s: yes
... preflight shows 150ms improvement
... beta canary is generally slower (probably due plugins?)

slightlyoff: 150ms out of ..?

n8s: ~5s or so
... it's big
... we're not working on offline mode but experimenting

slightlyoff: do your tests serve a shell like this?

n8s: no
... using machine learning to push content to the page
... "early flush"
... with the shell we have to pay attention to versions of javascript on the page which gets nontrivial
... [on slides] push safety
... lot of work going into fixing push
... making sure all servers understand old AND new resources
... pretty messy rewrite of fundamentals
... thread safety between activating and installed worker
... plans to launch sw for caching in chrome in the next two months

flaki: why not other browsers?

n8s: streams and preload mostly
... [on slides]

slightlyoff: does the first one put any html on the page

n8s: populating partial page content

pieter: getting resources early on the page

n8s: bytecode caching turned on was a great improvement and got us to neutral eventually
... hope to see these exposed

slightlyoff: our latest plan is to be transparent on this
... we hope to expose it via ignition in turbofan[?]
... we are looking into these things re: webassembly, or preparsing css, and we are throwing these away today

JakeA n8s slightlyoff: [chat on implementation of the caching and optimization parts, and exposing the result to the developer]

wanderview: [..] anything that wanted to store metadata on the object could do

slightlyoff: cache.put works similarly
... webassembly folks are agitated not having guarantees (we probably won't have any of those)

wanderview: wondering if it would be worthy of exposing this sidechannel on the object

n8s: we'd like that

slightlyoff: not exposing the bytecode

wanderview: not the bytecode but some api

slightlyoff: maybe we could add more things onto the cache api
... it wasn't designed and is not a very good database

n8s: at the bare minimum if cache.put just waited until the optimizations are done, that would be great

JakeA: now that we have Apple in the room, we were talking about BFcache
... so what mozilla does, it's no longer accessible via matchAll et al, but comes back to life
... it provides a guarantee if the client is effectively gone it makes it Really gone

bradee-oh: do you fire any event on the SW itself when the client goes into the bfcache??

<falken> bradee-oh talking. do you fire any event on the SW itself when the client goes into the bfcache?

wanderview: ... we were wondering on exposing this as an event control/uncontrol

bradee-oh: so the behavior JakeA mentioned we're willing to also do this

wanderview: our goal is we want to have BFcache on sites that use it, but keep the state as transparent and consistent as possible

n8s: it's actually a very big perf optimization!

wanderview: I notice when I don't have it, we should get more data

JakeA: chrome is implementing as well

wanderview: do you enable https?

bradee-oh: we moved on few years ago, it's enabled on ~most https site

<kbx_> In Chrome, back/forward goes to SW as an implementation side-effect. We currently don't have a bfcache, we do a regular-load-preferring-cache IIRC which triggers the usual SW path... bad for perf.

<tyoshino> afternoon session started

jungkees: [on whiteboard] explaining spec fundamentals
... browsing context...

Domenic: ...which is like a tab

jungkees: yes, or an iframe
... window -> environment settings object -> realm
... document is installed in that window
... we create an environment object called a "reserved client"
... after the navigation is complete, our new (window -> env. s.o. -> realm) object we copy some properties (like active service worker) from our reserved client o the env. s.o.

domenic wanderview: in the replacement case, when initial doc was an about:blank, no new window object is created, but the initial window is reused

jungkees: according to spec, "client" is an environment setting object (incl. reserved clients)

<slightlyoff> https://usercontent.irccloud-cdn.com/file/jdGgkw5c/IMG_20170403_131731.jpg

<tyoshino> wanderview explaining how Gecko works on the whiteboard

wanderview: [on whiteboard] gecko impl

jungkees: ns is for "Netscape"?

Domenic: or.. namespace?

wanderview: it's Netscape :)
... apologies for the gecko-isms
... our fetch implementation internally uses a side channel
... as you navigate innerwindows are replaced - and only have one document, except for the case when about:blank is replaced, in this case innerwindow had two documents
... trying to implement reserveclient


wanderview: clientsource is our implementation of client (has id etc.)
... on loadcomplete I get a second clientsource
... about:blank gets execution ready _again_
... we hide url because it might be wrong
... gecko as shipping today represents clients as documents, and that's wrong
... spec's "window/e.s.o./realm" is inner nsGlobalWindow

JakeA: my worry is... if it's a redirect, it will get a new fetch event

wanderview: before that, the about:blank page -- should it show client id for the already execution ready about:blank or a new reserve client
... ?
... boris said one can't know a priori whether the blank client will ever be replaced or not

JakeA: if I create an iframe and make fetch() do evil stuff...

Domenic: everything stays the same

JakeA: what I rewrite fetch to do evil stuff and redirect cross-origin

Domenic wanderview: cross-origin is different, a new window is created ... I think?

<Domenic> Confirmed cross-origin is different

<Domenic> https://html.spec.whatwg.org/#initialise-the-document-object step 3

<Domenic> If browsingContext's only entry in its session history is the about:blank Document that was added when browsingContext was created, and navigation is occurring with replacement enabled, *****and that Document has the same origin as the new Document******

wanderview: reserveclient assumes the target is going away--and in this case it's not
... my plan. I'm gonna implement this, and reuse the reserve client..

JakeA: currently (without this mess) a reserved client id is when we can say a client will come to life, perhaps

wanderview: it's not replacing a client but it's going "into" a client
... I think we need to better define the attributes we are putting onto the fetch event

JakeA: makes sense...
... knowing which client you replacing is useful.
... when target/client/reserve is different [..]
... we lose the case if I'm trying to assing caches to clients...

wanderview: you can't treat it as a reserveclient, it won't receive post messages

slightlyoff: can we just assign it a different type?

JakeA: about:blank is a windowclient...

wanderview: we could have something like "if you start replacing about:blank... treat it as a reserveclient"... but then what if it fails... ugh, more special cases created, a deeper hole

slightlyoff: I'm just trying to figure out where to distribute the information

JakeA: if you postmessage the client where it goes?

slightlyoff: to the about:blank?

JakeA: but then you cannot buffer messages!

n8s: this is already a huge special case

wanderview: we buffer until "execution ready"--but when is that?

JakeA: I think we already covered this in the spec

wanderview: add an option to the postmessage? (option:delayAfterLoad)

Domenic: I'd like to have a mental model & be able to explain it to developers
... document.open creates a new global in firefox

wanderview: yes

<kbx> There is demand for a postMessage that delivers (promise based?? => resolves?) whenever the destination comes up. Today, folks are spamming postMessage until it works.

Domenic: but not everyone's is so straightforward...

JakeA: what facebook does here, you do iframes?

n8s: I think it sounds reasonable to change clientid, not change the global...
... this is a pretty complicated edge case, I cannot see too many running into it [?]
... you should know what the state are, what's safe or not safe

wanderview: I think this is already very complicated due legacy & not want to complicate it any further
... I want to be able to say a client is just an e.s.o.
... what I like about the client api, it's making our implementation better

JakeA: ""service worker is not designed well""--but in reality it's just delivering you 20 years of junk you never heard about

wanderview: ~~you wanted primitives!~~

n8s: in theory developers should be able to deal with this, it's already a pretty esoteric usecase

wanderview: if you create an application that does 5 redirects you already in the thick of it!

<JakeA> https://github.com/w3c/ServiceWorker/issues/1091

JakeA: about:blank we have talked to death...

wanderview: in about:blank replacement case we ruse about:blank


<JakeA> https://github.com/w3c/ServiceWorker/issues/1090

n8s: if you're already able to control it, you'll be able to deal with it -- if not, you're not gonna know about it e

wanderview: I'm proposing for the reserve client we shouldn't have clients.claim

JakeA: deal

<JakeA> https://github.com/w3c/ServiceWorker/issues/1080

JakeA: the intention is the most recently used one to come back
... e.g. for push one doesn't one to open a new window, but focus the most relevant one
... this is an edgecase...
... question is: what happens? what order comes back (for the all-nested iframes)
... document.hasFocus is all set the same time

wanderview: currently we focus on the window

JakeA: yeah that's it

wanderview: I thought you wanted the most recently focused iframe?

JakeA: I might have changed my mind

wanderview: should we close?

Mek: we store the focus time, we just don't expose it
... but we sort using that time...

slightlyoff: I thought we exposed this, but since we don't, we should just move on.
... let's say I click on an innerwindow (and I have it focused) do we focus the outer window?

wanderview: yes

slightlyoff: but then we are losing data, the specificity of what the user clicked is lost

wanderview Mek: but: both the iframe/inner window and outer window is focused the same moment

n8s: if you care about this usecase you can still look the page hierarchy

JakeA: so what are you suggesting?

slightlyoff: I wish we have more data etc.

n8s: if you're gonna do something special, you will look at all the results!
... if we are looking for simply the "most used" usecase, it should be the most relevant main window

JakeA: ancestor origins will give you the "nestedness"

wanderview: how is that going?

Domenic: ancestor origins? well, annevk has a patch...

aliams: so is it the outer window?
... so is it *always the outer window?

wanderview: no specific rule
... rule is creation order, which usually be the outer-window-first

n8s: people gotta be relying on this for push notifications
... if you would care more deeply then "just the window", you're probably gonna build some kind of special handler...

JakeA: i've been successfully talked down.

<wanderview> jungkees: https://bugzilla.mozilla.org/show_bug.cgi?id=1293277

<jungkees> wanderview: thanks

<JakeA> https://github.com/w3c/ServiceWorker/issues/1078

today I'm just taking a timestamp

wanderview: again, we're referencing values (creation/focusedtime) that are unspecced

<JakeA> https://github.com/w3c/ServiceWorker/issues/1035

JakeA: bf-cache. done.

jungkees: we are basically postmessaging a non-existing, to-be-created global, it's currently being specced

JakeA: and we are planned to buffer everything until it becomes execution-ready?

jungkees: ys

<JakeA> https://github.com/w3c/ServiceWorker/issues/1034

wanderview: mozilla's proposal is empty string
... we don't really have a url until the fetch completes...

jungkees: we just set it to an empty string and wait for the navigation to be done, and then set it to the finalized url
... my problem is just client.claim

JakeA: we decided that clients.claim won't affect reserved clients

jungkees: did we?

wanderview: we talked briefly about this earlier

jungkees: [..]

wanderview: [..] skipwaiting

jungkees: worried about when a new, more specifically scoped sw being installed

jungkees concerned about implementation difficulties

falken: I don't see how this could be any different from current impl when we do implement reserved clients

wanderview: we just create an ID, we don't have to instantiate it - we don't need any other part of the browser know about it (yet)
... what if claim calls on a more specific scope, does not see the reserved client, which comes online and is not controlled

falken: I think it's okay to not control that client, it came online later
... I think it's a less important edge case

wanderview: this also ties into other attributes on client
... like visibility, focus etc.

JakeA: you wanted to guess some of these by target slightlylate

slightlyoff: I'm not glad frametype is gon
... bunch of question remain: how does one use client
... I think we should give people as much information as we have

JakeA: for size and visibility you could look at target...

slightlyoff: we don't have examples, we're talking about how the system works

JakeA: we're talking edge cases

slightlyoff: but people are affected by these
... someone trying to navigate. should I focus the existing window there? is it an iframe? in that case I shouldn't be focusing it...
... there are a set of things one might want to operate on

slightlyoff this is not after navigation, but during navigation

slightlyoff JakeA: [talk about fetch event navigation semantics, and preventing navigation but instead focusing an existing page]

n8s: the email example is descriptive
... why shouldn't a link from an email reuse the existing facebook window instead of opening new tabs all the time?

slightlyoff JakeA: [intercepting the fetch event]

falken: everybody keeps talking about frameType should we talk about it?

slightlyoff: I don't want to die on this hill but I don't think we should remove it

salva: [...]

JakeA: this sounds like the launchEvent we just discussed
... it's a V2 thing
... back to frameType
... vs ancestorOrigins
... top-level and nested you can get from ancestorOrigins... none you can get...

slightlyoff: you _can_ get it, but have to work it.

wanderview: I almost removed it but realised we don't yet have ancestorOrigins yet so I haven't

slightlyoff: I'm not against saying we shouldn't have both

falken: how about not actively removing it until we have something to replace it, and don't remove it until we have an idea of usage

JakeA: so we put it back to the spec marked with "at risk"?

slightlyoff: yes, that's my preference

Domenic: ..should we just put it on the client?

reopen https://github.com/w3c/ServiceWorker/issues/732#issuecomment-291056364

<JakeA> https://github.com/w3c/ServiceWorker/issues/1031

discussed earlier

<JakeA> https://github.com/w3c/ServiceWorker/issues/1030

JakeA: same origin redirects are reused

wanderview: this is just spec def of "execution ready"

jungkees: [explains]

wanderview: why do we have two states?


it's dynamic

wanderview: ah, it's a snapshot.

<jungkees> https://w3c.github.io/ServiceWorker/#create-window-client

jungkees: when this algorithm is invoked, we copy the value of execution ready from createwindowclient's reserved state

Mek: [..]

wanderview: I'll have to look more deeply into the spec
... client.focus & client.windowopen requires interaction, but client.navigate does not, is that okay?

n8s Mek: yes

wanderview: gecko has a bug where it focuses the tab for sameorigin requests
... and there is nothing preventing client.navigate to navigate to cross origins-right?

jak ea:yes

JakeA: I'm excited about upload & transform streams

Domenic: I forgot how upload is important in the SW space

JakeA: ... I know we fail on redirect

wanderview: what was this?

JakeA: if a redirect happens that wants to replay the stream..
... this is the case when you get data from the camera and stream it straight into the server

Domenic: will collect this stuff into a list until after break

JakeA: break!

Domenic: [on slides] showing transform streams https://usercontent.irccloud-cdn.com/file/yL83sNu0/IMG_20170403_154533.jpg

wanderview: transferability makes them essentially consumed

transferability: take the readable data of the stream and make it available to the main thread

wanderview: the other way would be postmessaging

Domenic: I have an example code to do this without transform streams & transferables

salva: does the worker keep the sw alive?

Domenic: no it's the other way around

JakeA salva: we need an easy way to say "waituntil(stream_is_done)"

wanderview: [..]

Domenic: that's a great identified issue!
... "get the data from A to B, pretty promptly"

wanderview: it doesn't have to be a push stream, it could be a pull stream w/ backpressure

Domenic: exactly, no spec yet, but this is the plan
... avoiding copies -- maybe with typedarrays?

wanderview: also, native streams

Domenic: after the call is done the element is detached (neutered), I won't be able to touch it

asuth: are you saying you can't add a second transferable list?

JakeA: are we departing from node impl with that completely?
... or that wasn't the point ever?

Domenic: not neccessarily

asuth: you can always write a helper that traverses the object graph and extracts the list of transferrables.

<falken> yhirano says that respondWith transferring doesn't have to preserve byte-chunk boundaries...

Domenic: how we specified respondWith transfering does not preserve chunk boundaries

JakeA: we had a request from developers to pass certain fetch requests onto other workers, this makes it possible

Domenic: a community member came along and wrote a spec, some tests
... not exactly the direction we would like to be heading to but still was very helpful, and raised lots of issues

JakeA: wonder if you could work it the other way around, respec messageports upon streams

Domenic: [proposes worklets/serialized command]

wanderview: there might be some custom you can't transfer
... [first example] [..]

Domenic: only one thread can access the stream at any time
... my take on this is "respondwith will take it lao

*will keep it alive

JakeA: in my demo I do streaming

<Domenic> I am pretty sure this is the long thread where we ended up dropping rs.closed? https://github.com/yutakahirano/fetch-with-streams/issues/15

JakeA: i'd like to have close() promise as now I have to return a promise AND a result, would be great!


falken: currently this is more a side-effect but generally we want to kill the service worker
... maybe we can cut back on memory use but the easiest, most effective way is just to kill it when we don't need it

JakeA: I don't think we ever gonna do web sockets in SW
... they're effectively deprecated


JakeA: let's come back to this after the break

wanderview: we have innersource in spec that we could use for the download case

<JakeA> https://github.com/whatwg/fetch/issues/492

<Domenic> First part of https://github.com/w3c/ServiceWorker/issues/1026#issuecomment-267608596 is also interesting

JakeA: Notification icons weren't loading offline, so we added this enum to be able to specify what kind(s) of service workers should the request go through
... there was a request to put this on fetch options so one can define it themselves

n8s: it is a potential source of performance issue
... we want to access some urls outside of service workers
... when we know we don't have them cached and don't want them, either

slightlyoff: so you don't want to cache the request's result?

n8s: no, this is a one-time request

Domenic: this poses a lot of followon issues, as then one wants to specify fetchoptions on all kinds of HTML elements which clutters up the dom/spec with fetchoptions

slightlyoff: [..]

Domenic: this sounds a lot like to me like a service worker

slightlyoff: it's not. it' more like the preload scanner. it doesn't have access to caches for example

Domenic: we should add a single attribute, possibly json

slightlyoff: doesn't support bunch of things like fonts and css

JakeA: somebody specced this for css as url options
... we need to do this anyhow

asuth: for media, this could just be source object

surma: maybe let's just keept this to js, and not add things to platform right away, this sounds like a very specific usecase

JakeA: any objection against the fetchOption
... security?

n8s: one can unregister the service worker if they already have access to js, not an issue, really

[discussion on enum values and how they relate to spec lingo]

wanderview: just have all or none?

Domenic: yeah just be conservative

JakeA: all would go back to my fetch handler?

surma: sometimes that's exactly what I need

Domenic: empty string instead of none?

n8s: naaah

<Domenic> Three states: empty string ( = default), none, all.

<Domenic> But implementers are skeptical of all; it sounds hard.

<Domenic> surma: all would be very useful

<Domenic> surma: otherwise you have to start synthesizing fetchevents to call onfetch() with

wanderview: it could be a footgun that's hard to detect
... it's hard to track recursion since everything is async

asuth: is there a reason one can't return a redirect?
... it would be in follow mode right?

JakeA: yes

good as a v1

JakeA: allowing on html/css is where it gets tricky (weird)

[discussion on taking this further]

slightlyoff: this is a stepping stone, to any idea, be that a crazy worklet-based followup

<Domenic> https://github.com/whatwg/streams/issues/480

[discussion on request-response mappings and the discussed earlier exposing of request/response/cache proposal]

Domenic: if you can't reuse a url it's not a url

wanderview: it wouldn't be an easy win, we do reload urls in the browser today and they break

<Domenic> Old related issue: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23502

asuth proposes a "responsefactory"

slightlyoff: pulling caches in here is interesting, although not really what we want

yhirano calls out opaque responses as a hurdle on blob object url approach

[discussion on headers' availability and spoofing/synthetising those]

Domenic: we just don't have enough people on the room sympathethic to responsive images to justify covering the srcset case in a proposal, but we'll do this

wanderview: we should wait with that before propagating out any bad decisions perhaps

<inserted> Domenic: Fair enough. Let's not spec the srcset case in…

wanderview: if you synthetise a response you cannot give it a url, not even via the service worker


Domenic: 2013 version of src object in the original proposal the url is empty string...

JakeA: fetch cancellation
... somebody will be disappointed
... https://github.com/whatwg/fetch/issues/447#issuecomment-281731850
... on abort - you don't want to tell the user something went wrong
... is the signal neccessary or should we just pass the controller?

slightlyoff: separation of concerns..?

JakeA: how separate it should be?

slightlyoff: I don't like "signal"

Domenic: will this abort the stream?

JakeA: yes
... with an abort error
... what kind of controller we have? where is it from? what about window fetches?
... the "merged" proposal of signal/controller has a "recreated" controller on the SW scope, not the same

Domenic: what happens to the setPriority?

JakeA: one fights with the main thread on that

wanderview: I agree same-thread fetch cancellation controllers shouldn't be sync

JakeA: the signal is all intent-based
... the fetch observer will give you what happened

falken: I think people want more clear errors from fetch
... aborterror might be problematic

JakeA: "x" should mean a different error..

falken: so "x" is also an aborterror?

JakeA: yes
... n8s you do some magic if the browser displays an error

n8s: yes [..]

JakeA: I wonder if the fetchobserver should be the place we expose this

Mek: expose a proper network error?

<inserted> JA: yeah unless it's a clearly user-triggered abort. There is more of this kind of stuff to think about in a wider context

<chaals> Domenic: Hmm. don't use octet, use an enforced range on a normal kind of number

yhirano__: notification dispatch causes issues [sync notifications?]

JakeA: when you call "abort" it's best effort.

wanderview: is it?
... I'd expect the browser to force a rejection?

chaals: why?

wanderview: to signal the consumer the fact of the abort
... I don't have a strong expectation, but I was surprised to have received data out of JakeA's example code even though I said abort

Mek: is it possible to read the rest of buffer once you have aborted??

JakeA: no
... if you are interested in partial data, there's a streams api

salva: it might be still useful to be able to peek into the remaining buffer

JakeA: if you were using streams you could just refer to your own buffer
... you are not aborting from the abort, but recovering from the error

salva: for a slow resource I might have already received all the data I need?

JakeA: but in this case you would be using streams anyway

Domenic: how do you feel about splitting this to base classes that could be used by eg streams?

JakeA: cautiously interested

Domenic: subclass, but baseclass has abort only

wanderview: I raised a concern about keeping synchronous getters and keeping them up to date

Summary of Action Items

Summary of Resolutions

    [End of minutes]

    Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
    $Date: 2017/04/12 05:55:02 $