kbx> A CIRC user
agenda: w3c/ServiceWorker#932
14:20 first up: w3c/ServiceWorker#564
14:22 OCSP implemented in Firefox, Webkit but not in Chrome
14:23 Apparently removed https://www.imperialviolet.org/2012/02/05/crlsets.html
14:24 fetch are done from a privileged context not content. Similar in Webkit.
14:24 should not been seen by SW
14:25 jungkees: matter of finding the right spec and make it transparent to SW
14:25 w3c/ServiceWorker#703
14:26 Jake explaining the context of the issue.
14:26 → ehsan_ joined (~ehsan@2607:f0c8:8000:80e0:959c:ac1e:4e4d:6be5)
14:27 K A CIRC user
Ben mentioning that Range behavior differs across different browsers
14:28 Jake: resolution is stated in the issue (label=decided); just a matter of updating the relevant spec.
14:30 w3c/ServiceWorker#710
14:32 Ben: difference between HTTP cache and Cache API in terms of matching HEAD and GET (not true in the former, currently true in the later)
14:33 discussion about POST, for which we currently don't allow Cache.put
14:34 Ben/Jake: maybe we could do the same for HEAD?
14:35 A
+1
14:36 K A CIRC user
the risk is probably low enough to make the change
14:37 Ali: is the expectation that Cache API should always match HTTP cache behavior?
14:37 Jake: not always, for instance the Cache API can store different vary responses
14:38 Jake: in terms of matching it tries to follow the HTTP cache. The store multiple "vary" difference is actually allowed by the HTTP cache but no one does it.
14:39 s/by the HTTP cache/by the HTTP cache spec/
14:39 w3c/ServiceWorker#732
14:40 Jungkees: remaining open questions: ancestorOrigins and annevk's question about auxiliary
14:41 Jake: checking the spec; apparently anything with an opener is an auxiliary
14:43 decision: remove frametype in v1; wait for use cases for v2
14:44 Ehsan: question about where ancestorOrigins should be
14:45 Jake: windowclient
14:47 w3c/ServiceWorker#765
14:47 Jungkees: needs work in HTML spec; probably not worth discussing in this wg
14:48 Ben: is there a way for a SW to know that it started to control a new client? can it be done via Fetch
14:49 Jake: not in an about:blank case where there is no fetch event
14:49 Ben: should we consider adding a new surface for this
14:49 "start controlling event"
14:49 Jake: sharedworker has connect which feels similar. for V2
14:51 W Ben Kelly
we have a jury-rigged video setup here if people want to dial in: https://v.mozilla.com/flex.html?roomdirect.html&key=Gv34MhmZaRNp
14:51 K A CIRC user
Jake: on the other hand, letting SW know about clients going away is probably not a good idea, because it would be observing GC
14:51 W Ben Kelly
please let us know if you do since we need to start using the mic's more explicitly
14:52 K A CIRC user
14:53 Ben: can change it. what would be best?
14:53 Jake: feels like something is needed in IDL
14:54 "should not be able to call once the window is gone" thing
14:54 Ben: Boris said he ran into web compat issues when he tried to not allow script running
14:56 Sam: we also keep the iframes alive. but not consistent, spec are vague, hard to change.
14:56 Sam: script can run, we can't stop them.
14:57 Ben: when you do a frame.remove, we no longer control it
14:58 Sam: you don't reload the iframe? in webkit, I think we do. Goes back to when we tried to do a thing called "magic iframe".
14:58 Brady: how about an event "the client changed"
14:59 Brady: clients changed, onclientchange...
14:59 Jake: controlled is easy but clients changed seems harder
14:59 Ben: probably has to tied into the lifecycle for perf reasons
15:01 Ben: if we only notify for onclose, technically its not GC.
15:02 Jake: feels similar to unload
15:02 Nathan: it's already kind of exposed
15:03 ⇐ sp1rs quit (~sp1rs@106.51.64.172) Remote host closed the connection
15:03 K A CIRC user
Ben: can we make at least a statement
15:04 Ben: our wpt tests make .remove uncontrolled
15:04 Sam: if Blink and Webkit are consistent, write it down.
15:05 s/Webkit/Gecko/
15:05 Ben: reject promises, properties return null/undefined
15:05 Ali: we empty the object once you detach. inferring from window.navigator
15:06 Ben: navigator still exists in gecko/blink
15:08 Ali: replicated the example.
15:08 Ali (showing traces)
15:09 Ali: when trying to spit out what's inside navigator, it works until i close the window
15:09 tried with navigator and a few other
15:09 Ehsan: vastly different from what we have. probably breaking things
15:10 Jake: developers probably don't expect that this would work
15:10 Ehsan: for methods, yes but for properties?
15:11 Ben showing a new test exercising current behaviors. Action items: import in blink, adjust.
15:11 Ali: +1 on adding a warning "not guaranteed to work"
15:12 [15 minutes break]
15:12 → Mek_ and sp1rs joined ↔ ehsan_, kbx and n8s nipped out
15:48 K A CIRC user
[discussion about reliance on global scope, using multi SW to parallelize fetch requests]
15:50 → Garbee joined (uid21171@gateway/web/irccloud.com/x-mbeamisroqymxeaq)
15:51 K A CIRC user
discussion about threading debugging
15:52 Sam pointing out that multi threading debugging will be a thing eventually (e.g. js)
15:53 Sam: from a perf perspective, what is the threadoff between serialization of fetches vs. parallelization. Or are you hit by other synchronization issues?
15:53 Jake: a lot of it is already parallelized(e.g. network side)
15:53 Nathan: noting the impact on startup.
15:55 Jake/Kenji: mostly due to current design decision in Chrome where we rely on the main thread which unfortunately tends to be busy at startup.
15:56 Kenji: we have a plan to move away from relying on the main thread which should vastly improve startup times.
15:57 Ben: should the browser have the flexibilty of starthing a new SW thread if the existing one has been busy for a while on handling a fetch event.
15:57 Jake/... : yes
16:00 Jake: we can still go back to the developers who use SW and talk about issues with relying on the global scope. Restricting the multiSW optimization via an opt-in is a last resort
16:10 Ehsan: there are good use cases for global scope sharing, the push example by nathan
16:10 Nathan: for instance, we can have the new event wait for the current event to be processed.
16:11 Jake: you could solve this via IDB
16:11 Nathan: yes but tricky for the new event wait for the current event scenario.
16:13 Nathan: the other use cases is probably more relevant (the ability to use global state to ignore a subsequent navigation, in order to show the Navigator's default error page for instance)
16:18 Action item: find the global scope use cases and identify solutions.
16:21 ↔ sp1rs and Mek_ nipped out
16:22 K A CIRC user
Sam: would like to be able to have the ability to use multiple SW threads. still fine to change the 2 existing implementations regarding the global scope inferred expectations.
16:22 ⇐ n8s quit ↔ ehsan_, kbx and sp1rs nipped out
16:46 K A CIRC user
16:46 → n8s joined (~textual@199.201.64.2)
16:46 K A CIRC user
Jungkees: needs Fetch spec change.
16:47 w3c/ServiceWorker#811
16:47 Jungkees: will update the issue.
16:47 w3c/ServiceWorker#813
16:48 Jake: last resolution (w3c/ServiceWorker#813 (comment)) sounds bad
16:49 Ben : in our implementation we persist the security blob thing. The page looks at it, "is it secure?", it should all just flow back.
16:51 Jake: show a mix content warning: 1. on request, 2. if I've requested HTTPS but the response comes back from the Cache with HTTP, we would want to show a mix warning
16:51 Sam: what is the behavior with shared workers? Do you taint all of the pages associated with the shared worker?
16:52 Jake: the fetch has a client associated with it, if the client is not a window client, then you can't (because there would not be any place to show the MIX warning)
16:53 s/the fetch has/the fetch event can have/
16:53 Sam: what about importscripts?
16:53 Jake: good point.
16:54 Jake: should fail because there is no window.
16:57 ⇐ ehsan_ quit (~ehsan@2607:f0c8:8000:80e0:91b8:f43c:28cf:da5e) Remote host closed the connection
16:57 K A CIRC user
[lunch break: duration = ~1 hour 30 minutes / up to 2 hours]
16:57 → Guest6 and ehsan_ joined ⇐ bradee-oh and Mek_ quit ↔ weinig, kbx, n8s and sp1rs nipped out
19:02 K A CIRC user
19:02 Jungkees: blocked on IDL work
19:02 w3c/ServiceWorker#829
19:04 (spec wording)
19:04 w3c/ServiceWorker#834
19:04 ⇐ sp1rs quit (~sp1rs@106.51.129.38) Remote host closed the connection
19:06 K A CIRC user
Jungkees: we should use the HTML latest definition
19:06 w3c/ServiceWorker#850
19:08 Jungkees: Takeshi from Google is working on the stream spec, has a PR for this issue. Should do it.
19:08 w3c/ServiceWorker#855
19:09 reference to a situation that can't be triggered anymore
19:09 simple spec fix
19:09 w3c/ServiceWorker#856
19:10 Ben: this is about when you register while there is already a newer SW registered, the spec says just retun the registration object.
19:10 Ben: there is a mention about limiting this in the case where the newest SW is active.
19:11 Jungkees: this was probably before we added the queue
19:11 Ben: ultimately, it's about cleaning up the spec.
19:12 Jake: doesn't make sense that we would check for Active.
19:13 Jake: not needed
19:14 → sp1rs joined (~sp1rs@106.51.129.38)
19:16 K A CIRC user
Nathan: no-op is best because it works better when registering on all pages.
19:18 Jake/Mek: think it makes sense to get rid of the check.
19:19 w3c/ServiceWorker#870
19:19 ⇐ sp1rs quit (~sp1rs@106.51.129.38) Ping timeout: 260 seconds
19:21 K A CIRC user
Jake: being able to distinguish between same tab nav, new window open, and replacing a client(?)
19:22 Jungkees: need more time to think about it.
19:22 w3c/ServiceWorker#873
19:26 (bump priority of implementation)
19:26 w3c/ServiceWorker#875
19:27 Sam: is this actually well defined?
19:28 Nathan: talked with Kenji about changing the reload behavior for instance.
19:28 Ben: the request object should reflect what the browser does.
19:29 w3c/ServiceWorker#879
19:30 Sam: pros and cons?
19:30 Jake: Cache API can be used in Window context, not tied to SW.
19:30 Sam: similar to fetch
19:30 Ben: fetch had more reasons
19:31 Brady: value of keeping it in SW to avoid Developers using it as a key-value store?
19:32 Jake: the abuse is happening within a sw context so...
19:33 Brady: concern, some JS library use it so much that it would impact fetch performance.
19:35 → Mek_ joined (42cfc116@kde/mkruisselbrink)
19:36 K A CIRC user
Ben: if someone wants to pull it forward then makes sense to move it standalone.
19:36 Jake: not high priority, not v1.
19:36 w3c/ServiceWorker#881
19:37 Jake: will happen on Saturday
19:37 w3c/ServiceWorker#882
19:37 Jake: the answer is use waitUntil
19:38 Jake: if you are adding to the stream, you need a way to keep the SW alive while this is happening. the current solution is to use waitUntil.
19:49 → sp1rs joined ↔ kbx_ popped in ↔ kbx nipped out
20:04 K A CIRC user
20:05 Jake: cache.addAll currently resolves when headers come, which is weird. Resolution on the bug. Agreement?
20:05 [yes]
20:05 w3c/ServiceWorker#887
20:06 Ben: we should have an order, proposed one.
20:06 Jake: like it.
20:06 w3c/ServiceWorker#888
20:07 spec wording issue
20:08 w3c/ServiceWorker#890
20:09 Ben: should the frozen tabs appear (e.g. in Chrome, tabs that don't get used for a while)
20:10 Sam: paused after 15 seconds (no navigation on unpausing), and then can be purged but it will be a navigation in that case.
20:10 Sam: if a page is in the bfcache, we should treat it as non-existent.
20:10 Jake: explaining the case of Push => looking for an existing tab => reuse it
20:11 Jake: issue in Chrome with the tabs we kill, no solution yet
20:12 suggestion of making these a different type of client
20:13 Ben: this was a browser optimization that has been transparent until now.
20:13 Sam: solving the use case of the Push notification wanting to reuse an existing tab is desirable.
20:14 Brady: on desktop, open url, with exact match, would reload an existing tab: open from a command line, or an email.
20:15 Brady: or even from a push notification?
20:15 Jake: yeah, seems like something Chrome could do.
20:16 Mek: developers can look for existing clients, if not then open url and the UA can do what's best (e.g. reuse a killed tab)
20:17 w3c/ServiceWorker#892
20:18 hold on: w3c/ServiceWorker#890
20:18 above, was a tangent, not about 890
20:19 Jake: footgun for the web, losing access APIs from how you get called is sad.
20:22 Andrew: depends on the UI, if it's a popup in like the oauth flow we can't break it, if it's a new tab, from a user's viewpoint closing the other tab should be fine
20:22 Sam: window.open to a page with a SW. Just the very act of using SW make opener go away?
20:23 Jake: agree, reached same conclusion.
20:24 Jake: opened a bug about the security value of opener.
20:25 Sam: isn't the issue about the fact that there is an exfiltration?
20:25 Mek: no opener sever the connection both ways.
20:29 Jake: if you've got an opener referencing a non secure origin, you are not secure.
20:31 Ben: 2 issues, the spec doesn't say what we intend, and then we have the opener issue.
20:31 where the spec == fetch spec
20:38 Sam: anyone has data about usage of window.opener from a secure origins to a non secure origin?
20:39 Sam: we might as well go one step beyond and ignore the SW aspect if the usage number is low enough.
20:40 w3c/ServiceWorker#892
20:41 Jake: suggestion that if your navigation fails (error from SW, or some other kind of rejected response), right now you get a browser error. Is it sensible?
20:41 Sam: alternative?
20:41 Sam: doesn't the SW handle this?
20:41 Mek: the SW is buggy
20:42 Jake: or a bug in one of the SW implementation
20:42 Ben: potentially broken for a day as well
20:42 Sam: how does this compare with serving a bad asset or doing a bad redirect?
20:43 Sam: throwing a browser error can be valuable sometime.
20:44 Nathan: yes, the browser error page can be better equipped to troubleshoot issues.
20:46 Jake/Sam: the error page, could have a Try without SW.
20:47 Nathan: should split this in 2 issues (one extra for better UA errors pages)
20:48 Sam: how dev deal with these sort of issues?
20:49 Jake: if it's completely broken, every navigation will give you an opportunity to update.
20:50 Ben: one alternative to the "retry without SW" button, do it automatically if more than X nav failed.
20:53 sidenote: https://beverloo.github.io/budget-api/
21:03 discussion about rewarding well behaved SW, badly behaved SW.
21:17 ↔ kbx nipped out
21:25 K A CIRC user
21:26 (best to be opt-in) Jake: where would the opt-in reside?
21:27 Ali: when is this needed?
21:27 Jake: when you don't control the header, (e.g. github)
21:28 w3c/ServiceWorker#894
21:28 is related
21:31 kbx: can you end up with an inconsistent state of mix-match of versions between SW, importscripts?
21:32 Jake: yes but not peculiar to SW, devs already know how to deal with it
21:34 w3c/ServiceWorker#896
21:35 Ben: the exception should not have any effect beyond reporting to the console and aborting the event.
21:36 Ben: what about install event?
21:36 Jake: former, agree. install event, is interesting.
21:36 Ben: consistency would be good.
21:38 Jake: can you detect errors from events, or does the dispatching algorithm swallow them?
21:38 Ben: returns true/false but this is about preventdefault
21:38 Mek: spec says, if exception, report exception
21:43 ⇐ ehsan_ quit (~ehsan@66.207.193.21) Remote host closed the connection
21:47 K A CIRC user
21:47 decision: yes it should
21:48 w3c/ServiceWorker#912
21:48 remove
21:48 w3c/ServiceWorker#916
21:49 Ben: recently fixed in Gecko, Blink
21:51 w3c/ServiceWorker#918
21:52 remove
21:52 w3c/ServiceWorker#919
21:52 Jungkees: backported, kinda done with it.
21:53 Jungkees: will refer to the issue
21:53 w3c/ServiceWorker#922
21:55 need Domenic's WPT tests
21:56 w3c/ServiceWorker#931
21:58 Ben: probably don't need to change the algorithm.
21:59 Ben: get current set of promises, do all, recheck if the # of promises has changed, if not then done, if it did then repeat
21:59 Ben: does not seem like an observable change.
22:00 Jake: makes sense.
22:02 w3c/ServiceWorker#935
22:03 Jake: the question is if we want to allow what is described in the issue.
22:03 Ben/...: sounds like we do.
22:05 ⇐ Guest6 quit (~textual@66.207.193.22) Quit: My Mac has gone to sleep. ZZZzzz…
22:08 K A CIRC user
22:12 Ben: expect that waitUntil are independent of one another.
22:12 Mek: in chrome we don't early abort, we wait for the rest.
22:13 Ben: so Chrome is implementing what I'm proposing.
22:13 Mek: it's what the spec says too :)
22:14 Jungkees: going over the algo
22:14 Ben: the algo points to promise.all which fast fails if a single promise rejects.
22:16 Jungkees: the waiting for all is problematic
22:17 Jungkees: any better promises option then?
22:18 nope but libraries probably have what we need
22:20 ⇐ weinig quit (~weinig@66.207.193.22) Quit: weinig
22:20 W Ben Kelly
dinner at 8pm at https://goo.gl/maps/dP8VmNT1H3G2
22:21 recommended bar for drinks: https://goo.gl/maps/xx8AZR9NyMo
22:22 K A CIRC user
done for day 1
22:27 ⇐ kbx, n8s, Mek_ and sp1rs quit
Friday, July 29th, 2016
00:28 → Guest6, sp1rs, weinig, Mek_, ehsan_, asuth and ttung (was Guest64786) joined ↔ n8s and kbx popped in ↔ jungkees and Garbee nipped out
15:21 S
hey hey all; sorry I missed everything yesterday. When are things starting today?
15:22 ttung → tt
15:22 M<Mek_> 66.207.193.22 - http://webchat.freenode.net
slightlyoff: a little over an hour ago...
15:23 tt → Guest23753
15:23 M<Mek_> 66.207.193.22 - http://webchat.freenode.net
we probably should have tried better to take notes today, but issues should have notes
15:24 → kbx joined • Guest23753 → ttung
15:26 S
yeah, I've been reading the issues from yesterday; looks like a lot of progress was made
15:26 are y'all still on v1 issues this morning?
15:27 also, is there a dial in # or VC bridge?
15:27 (not sure when I'll be able to dial in, so no rush)
15:29 K A CIRC user
15:29 slightlyoff: we are past v1 issues.
15:30 Ben: we can make it harder but is there a better option
15:31 there is a proposal on the issue
15:31 Sam: what are the use case for storing opaque responses?
15:31 Jake: things like script, images
15:31 Jake: at install time it's less likely, cahcing stuff from your origin.
15:32 Jake: if you cache things as they are requested (e.g. avatars). The suggestion of not allowing caching opaque was made once but...
15:32 Sam: not suggesting that we do
15:32 M<Mek_> 66.207.193.22 - http://webchat.freenode.net
slightlyoff: I think there is some kind of vidyo thing to dial in, wanderview probably has details
15:33 K A CIRC user
Sam: anyone using opaque storage?
15:33 Nathan: not yet but it's nice because it will force v8 code caching.
15:33 W Ben Kelly
Mek_: slightlyoff: does this link work for you? https://v.mozilla.com/flex.html?roomdirect.html&key=Gv34MhmZaRNp
15:34 K A CIRC user
Nathan: right now only caching same origin but will eventually will cache cross origin assets.
15:34 S
this requires a plugin?
15:34 K A CIRC user
Nathan: eventually will stop using CDN because H2 is so fast but it will be a while
15:34 W Ben Kelly
slightlyoff: I'm not sure... I think there is a way to just dial-in with phone... checking
15:35 K A CIRC user
Jake: proposal suggesting bucketing the size
15:36 Jake: will penalize the dev because using opaque responses will be larger
15:36 Ali: the user will be penalized
15:36 Sam: you don't have to actually use the storage, you can lie
15:36 S
yeah; I think lying to some moderate degree is fine. Disk is cheaper than folks think
15:38 K A CIRC user
[discussion about how a developer could try to guess the truth; suggestion of randomizing the padding lie]
15:38 W Ben Kelly
slightlyoff: Call 1-650-903-0800, x92 then 9 and the ext then #5500, or: +1 800 707 2533, pin 369 - then 9 and the ext then #5500
15:39 K A CIRC user
Jake: we probably don't have the right experts to come up with a definite answer.
15:40 Ali: chatted with experts on MS. everytime you had something, make it unpredictable what the quota will be, 5-10% variation.
15:41 Jake: the method to get quota is in fact an estimate
15:41 Ali: ultimately, make it hard enough that it's not worth it / not effective.
15:42 Ali: timing wise, delay but then performance is impacted
15:42 Jake: not too worried about timing attack when getting it out of the cache.
15:43 Jake: the spec lets you abort early if an image turns out to not be an image.
15:43 S
Thanks, wanderview
15:43 K A CIRC user
Jake: if it's padded by a random amount, do it a thousand time, take the lowest.
15:43 Jake: probably not going to solve these.
15:44 Ali: as you mentioned already exists.
15:44 Ali: as you mentioned timing attacks already exists.
15:44 ⇐ sp1rs quit (~sp1rs@106.51.64.172) Remote host closed the connection
15:45 K A CIRC user
Ethan: mentioning that the researcher will probably present his findings, we can expect more ill intent usage soon
15:45 Jake: we should bump priority.
15:46 Ali: could we disallow opaque when no SW is around?
15:46 Mek: a SW could be created later though
15:48 S
I don't think timing is meaningful here. You can already see timings from iframes.
15:49 K A CIRC user
slightlyoff, yes agreement in the room as well.
15:49 Jake: we should find a solution for the quota attack
15:50 Kenji: need to reach back to our security experts for suggestions.
15:50 S
quota attack seems mitigatable with fudging and % lies. That's doable in the very short run and requires no API changes
15:50 K A CIRC user
slightlyoff, yes I think this is the current train of thoughts.
15:52 S
great!
15:54 K A CIRC user
15:54 (15 minutes break)
15:55 S
kbx: are you presenting the latency findings ahead of this issue?
15:57 K A CIRC user
yeah
15:57 http://goo.gl/4855qn
15:57 we will
15:59 → n8s and aliams joined
16:00 K A CIRC user
reposting link: http://goo.gl/4855qn
16:17 A Andrew Sutherland
gecko bug "Drop support for navigating to responses whose MIME type is multipart/x-mixed-replace" https://bugzilla.mozilla.org/show_bug.cgi?id=1276918 for
16:17 links to closed whatwg/html#1353
16:24 ⇐ n8s quit ↔ sp1rs popped in ↔ kbx nipped out
17:03 K A CIRC user
Jake: using the preflight pattern is only useful for the FB pattern?
17:03 Nathan: not sure.
17:04 Jake: postmessage will probably get the job done.
17:04 → sp1rs joined ↔ ehsan_, Mek_ and kbx nipped out • weinig → weinig|lunch
18:38 K A CIRC user
Jake: we've seen how SW are implemented in Chrome and what it means for latency, upcoming optimizations, ultimately it'll never be zero cost.
18:39 Jake: does the preflight idea sounds good?
18:39 Sam: not opposed but would like to find out if there are alternatives.
18:39 Sam: it's a good idea, what are the other potential use cases.
18:40 Nathan: in most cases it should be a win.
18:41 Sam: the term preflight doesn't sound adequate
18:41 Ben: speculative
18:41 Sam: precheck, global entry ;)
18:41 weinig|lunch → weinig
18:41 K A CIRC user
Nathan: important that it remains an optimization that the browser can use not must use
18:43 Ben: one case, a form post, we wouldn't want to do it
18:43 Ben: is this helping the non SPA case?
18:43 Jake/Nathan: yes, wikipedia case
18:44 Nathan: they can race it with their cache.
18:45 Jake: if there are URLs that you are not yet ready to control, it would be faster to let the network handle those.
18:46 Ben: there is use case, not sure if it's generic enough, the proposal is useful for it.
18:49 Jake: is this only for navigation?
18:49 Nathan: yes.
18:53 ⇐ sp1rs quit (~sp1rs@103.227.98.59) Remote host closed the connection
18:55 K A CIRC user
discussion about what to support, conclusion to start humble: dictionary
18:55 Sam: which headers do you want to add?
18:55 Nathan: custom header
18:55 Nathan: post time, revision number,
18:56 Sam: because you can't augment the URL
18:56 Nathan: yes
18:56 Jake: this API will seat in the registration object so that it can be updated anytime
18:56 Ben: including turning it off
18:56 Jake: yes
18:57 Andrew: need to be careful about guarantees around changes
18:57 Andrew: basically, don't want to have this mean "fsync!"
18:59 Jake: the promise should reject if the modifications are not allowed
18:59 Ben: if you unregister your SW, goes away
18:59 Jake: same rules for push and bg sync
18:59 Jake: once in place the browser will do this all the time
19:00 Jake: just one setting?
19:02 Jake: maybe a fetchmanager?
19:03 Nathan: early fetch?
19:03 S
BTW, at dinner, but like where this is going. Opt in seems great, not precious about name of "preflight"; happy to see streaming use-case explored
19:03 → sp1rs joined (~sp1rs@103.227.98.59)
19:03 A Andrew Sutherland
Early fetch is the best.
19:04 K A CIRC user
Sam: concurrent fetch?
19:05 S
"prefetch"?
19:06 K A CIRC user
Foreign Fetch
19:06 Mek: nothing in particular
19:07 w3c/ServiceWorker#839
19:07 Ben: by default we should check them all. Having an opt-out is fine though
19:08 ⇐ sp1rs quit (~sp1rs@103.227.98.59) Ping timeout: 264 seconds
19:08 K A CIRC user
Ben: didn't we do this because we had concerns about async importscript at the time?
19:08 (as in not check updates)
19:09 (discussion about server not responding, or 500...)
19:10 Jake: byte by byte happens on my SW and then it will go on importscripts
19:11 Jake: byte by byte happens on my script and then on importscript if mine has not changed
19:12 Andrew: you have the current graph, you can //ize the update
19:13 Ben: which Sw do we pick today?
19:13 Mek: the newest
19:14 question about the importance of the order of checks
19:14 Ben/Mek: not important
19:16 Jake/Mek: for 404, we do an update but the install will fail.
19:20 Opt-out?
19:21 Nathan: as long as cache control headers are respected then probably not needed.
19:22 Nathan: checking every 24 hours despite immutable is fine
19:28 → sp1rs and kbx_ joined ⇐ kbx quit
19:41 K<kbx_> A CIRC user
19:43 Ben: folks want to tweak the request, and all the primitives by fetch have landmines, instead of throwing, silently fail?
19:44 Jake: still not sure why navigate is special cased / throwing
19:45 Ben: complicated consequences to work through
19:45 kbx_ → kbx
19:48 K A CIRC user
above is about: whatwg/fetch#245
19:55 ↔ sp1rs nipped out
21:01 K A CIRC user
21:01 Ben: there is the abiltiy to override onfetch
21:02 Ben: long term think this aligns with the static route approach
21:02 Ben: too early to add such a huge surface at this point, would be great to see frameworks pave the way and use cases
21:03 Jake: they want a serviceworker for the serviceworker
21:04 ↔ ehsan_ nipped out
21:05 K A CIRC user
Jake: they want to be like foreign fetch
21:06 Ben: what we currently have is not great for composing. Importscripts work but tightly coupling
21:09 Mek: worklets?
21:10 Ben: feels like composing components to deal with network requests
21:10 Ben: probably won't have the bandwidth for this in a while.
21:18 ⇐ sp1rs quit (~sp1rs@103.227.98.59) Remote host closed the connection
21:18 A CIRC user
21:19 Ben: rejected fetch events, are users seeing broken website page for my website because of sw?
21:20 Sam: CSP reporting, it's valuable because you don't have the opportunity to notice that things are happening. whereas, in SW, the failures are detectable.
21:21 Sam: you could just fire a fetch to tell your server about it
21:21 Ben: the case where they have a bug and we show the broken website page.
21:22 Jake: one more example the not appropriate fetch request (tweaked)
21:23 Mek: if this is a navigation that fails, there is no client.
21:23 Ben: should we fix failing navigation?
21:24 → sp1rs joined (~sp1rs@103.227.98.59)
21:25 K A CIRC user
Andrew: what about if the error happens when you are offline and quota comes in...
21:26 Sam: have a log structure that indicates past failures, so that you could deal with offline issues that can be picked up later.
21:27 ⇐ sp1rs quit (~sp1rs@103.227.98.59) Remote host closed the connection
21:27 → sp1rs joined ⇐ ehsan_, aliams, weinig, Guest6, kbx, Mek_ and jungkees quit
Saturday, July 30th, 2016
00:30 ⇐ sp1rs and Garbee quit ↔ Guest6 and weinig popped in
Sunday, July 31st, 2016
10:24 → weinig joined ↔ sp1rs popped in ↔ franciscojordano, ttung, wanderview, annevk and asuth nipped out
Monday, August 1st, 2016
03:14 D Domenic Denicola
I don't really understand the preflight discussion in #920. It sounds like the idea is every service-worker controlled site will need double the requests now to get any content? How does this make things faster?
03:38 ⇐ weinig quit (~weinig@17.202.48.33) Quit: weinig
06:57 A Anne van Kesteren
I don't think that is the proposal we want. The goal is to do a request in parallel with starting the SW and then tell the SW about the response
06:57 For navigations
06:58 → sp1rs and Garbee joined
14:31 J Jake Archibald
That's what it is. And it's opt-in.
14:32 Won't result in a double request