Skip to content

Instantly share code, notes, and snippets.

What would you like to do?

kbx> A CIRC user


14:20 first up:

14:22 OCSP implemented in Firefox, Webkit but not in Chrome

14:23 Apparently removed

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: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: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


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: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 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:

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@ 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/

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@

16:46 K A CIRC user

Jungkees: needs Fetch spec change.


16:47 Jungkees: will update the issue.


16:48 Jake: last resolution ( 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:04 (spec wording)


19:04 ⇐ sp1rs quit (~sp1rs@ Remote host closed the connection

19:06 K A CIRC user

Jungkees: we should use the HTML latest definition


19:08 Jungkees: Takeshi from Google is working on the stream spec, has a PR for this issue. Should do it.


19:09 reference to a situation that can't be triggered anymore

19:09 simple spec fix


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@

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 ⇐ sp1rs quit (~sp1rs@ 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:26 (bump priority of implementation)


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: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:37 Jake: will happen on Saturday


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:06 Ben: we should have an order, proposed one.

20:06 Jake: like it.


20:07 spec wording issue


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:18 hold on:

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: 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: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:

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 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: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@ Remote host closed the connection

21:47 K A CIRC user

21:47 decision: yes it should


21:48 remove


21:49 Ben: recently fixed in Gecko, Blink


21:52 remove


21:52 Jungkees: backported, kinda done with it.

21:53 Jungkees: will refer to the issue


21:55 need Domenic's WPT tests


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: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@ 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@ Quit: weinig

22:20 W Ben Kelly

dinner at 8pm at

22:21 recommended bar for drinks:

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_> -

slightlyoff: a little over an hour ago...

15:23 tt → Guest23753

15:23 M<Mek_> -

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_> -

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?

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@ 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


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



15:57 we will

15:59 → n8s and aliams joined

16:00 K A CIRC user

reposting link:

16:17 A Andrew Sutherland

gecko bug "Drop support for navigating to responses whose MIME type is multipart/x-mixed-replace" for

16:17 links to closed

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@ 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@

19:03 A Andrew Sutherland

Early fetch is the best.

19:04 K A CIRC user

Sam: concurrent fetch?

19:05 S


19:06 K A CIRC user

Foreign Fetch

19:06 Mek: nothing in particular


19:07 Ben: by default we should check them all. Having an opt-out is fine though

19:08 ⇐ sp1rs quit (~sp1rs@ 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:

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@ 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@

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@ 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@ 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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.