<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
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!
:DDD
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?
yes
"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
*reserved
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
*reuse
<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?
jungkees:
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
[murmurs]
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
[right]
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
