| 04:04 | <MikeSmith> | you have any advice about how I should preparee fo/win 23 |
| 04:04 | <MikeSmith> | oofs |
| 13:14 | <smaug____> | hmm, I thought I knew how download attribute works with <a> |
| 13:14 | <smaug____> | but apparently I don't |
| 13:19 | <smaug____> | hmm, or perhaps server can still override the filename? |
| 13:49 | <wanderview> | JakeA: a couple times last week you mentioned the idea of returning a promise from respondWith() that would resolve after the browser consumes the response |
| 13:49 | <wanderview> | it didn't quite sit well with me and I couldn't figure out why |
| 13:49 | <wanderview> | I think I finally figured out what bothers me about it |
| 13:50 | <wanderview> | JakeA: wouldn't a promise returned from respondWith() essentially provide a callback exactly when we're no longer holding the service worker alive? its like a "now its unsafe" callback |
| 13:50 | <JakeA> | wanderview: yeah you'd have to do waitUntil( respondWith(stuff).then(…) ) |
| 13:51 | <JakeA> | Which is a bit :/ |
| 13:51 | <wanderview> | JakeA: or it gets an implicit extension for a micro-task... but feels difficult to explain with our current primitives |
| 13:51 | <wanderview> | or wonky at least |
| 14:06 | <JakeA> | We already have an extension for a microtask right? |
| 14:07 | <JakeA> | We talked about that so waitUntil( thing.then(() => waitUntil(anotherThing)) ) works |
| 14:08 | <JakeA> | hm, my code there is wrong. I mean: thing.then(() => waitUntil(anotherThing)); whatUntil(thing); |
| 14:08 | <JakeA> | hah, I mean waitUntil |
| 14:08 | JakeA | falls over |
| 14:56 | <JakeA> | wanderview: now I think about it, didn't we decide a separate fetcherror event was a better idea? |
| 14:57 | <wanderview> | JakeA: yea... I was just thinking about the respondWith() promise idea this morning |
| 14:58 | <wanderview> | JakeA: I guess I was saying "not only are we not doing your idea, Jake, but I don't like it either!!!!" |
| 14:58 | <wanderview> | sorry |
| 14:58 | <wanderview> | :-) |
| 14:58 | <JakeA> | haha |
| 14:58 | <JakeA> | Yeah, the event is better, as you can do something with it |
| 15:03 | <wanderview> | JakeA: now I'm trying to remember why we wanted FetchErrorEvent instead of just using the normal Worker global onerror... I guess its more explicit and we can provide a better method to "resume the connection" than just preventDefault() |
| 15:04 | <JakeA> | wanderview: yeah, preventDefault is really confusing in this case, since it'd make the default thing happen |
| 15:05 | <JakeA> | annevk: https://fetch.spec.whatwg.org/#http-fetch 3.3 - does this suggest a new generic network error is created? Devs have complained that Chrome presents a generic error rather than a more specific one. Does there need to be a spec change to allow the actual error to pass through to the navigation handler? |
| 15:06 | <annevk> | JakeA: yeah, we'd need to change the spec |
| 15:07 | <JakeA> | I'll file an issue |
| 15:07 | <annevk> | JakeA: and get security sign off |
| 15:07 | <wanderview> | annevk: I think the browser could just stash the specific type on an internal value... its never consumed by anyone but the browser |
| 15:07 | <annevk> | JakeA: that is the main reason all errors are the same |
| 15:07 | <JakeA> | Yeah, might need some same-origin checks |
| 15:08 | <wanderview> | annevk: JakeA: in firefox all network error pages are cross origin.. so i don't think the error type can ever be leaked to content... doesn't seem like a security issue to me... might be an issue for chrome with same-origin error pages |
| 15:08 | <annevk> | JakeA: even for that I recall folks not liking it, but there might be APIs exposing that now |
| 15:09 | <annevk> | wanderview: I thought we were discussing specific TypeError exceptions |
| 15:09 | <JakeA> | Hmm, I can't think of problems, but will make an issue and see if we can get someone security-minded to look at it |
| 15:10 | <wanderview> | annevk: not if its the same as the face-to-face meeting discussion... it was just showing the right network error page to the user... not exposing different exception types |
| 15:10 | <annevk> | Okay, I guess I'll follow up on the issue then 😊 |
| 15:11 | <annevk> | Not today, but likely tomorrow |
| 15:24 | <smaug____> | who might know about blink's MutationObserver implementation |
| 19:21 | <wanderview> | JakeA: how do you BroadcastChannel to a service worker? |
| 19:21 | <JakeA> | wanderview: new BroadcastChannel? It'd only work while the instance is alive |
| 19:22 | <wanderview> | JakeA: I guess each service worker thread adds an event listener to the BroadcastChannel ? |
| 19:22 | <JakeA> | Yeah |
| 19:22 | wanderview | goes to read BroadcastChannel... |
| 19:22 | <JakeA> | I don't think it's a problem, just something to think about |
| 19:22 | <wanderview> | JakeA: it might be worth pointing out that SharedWorker is either not implemented or not supported as a nested worker in any browser today? |
| 19:23 | <wanderview> | but we could make that a pre-req of implementing this? |
| 19:23 | <JakeA> | Good point |
| 19:23 | <wanderview> | JakeA: maybe pre-req is too strong a word :-) |
| 19:27 | <wanderview> | JakeA: I do kind of like the conceptual difference between SharedWorker and ServiceWorker in this design... ServiceWorker instances are ephemeral and fast... if you want synchronous coordination you pay the price and opt-in to SharedWorker |
| 19:27 | <JakeA> | Or IDB (maybe with observers too) |
| 19:27 | <wanderview> | JakeA: I guess an opt-in to "single thread always" for service worker could just be implemented as "all service worker instances open a SharedWorker and fire their event there" |
| 19:28 | <wanderview> | JakeA: I mean, the browser could implement it that way... no special logic beyond what the content could polyfil themselves |
| 19:28 | <wanderview> | JakeA: the browser would just be fixing up the global to connect a few things, etc |
| 19:28 | <JakeA> | Hah! Well, if you're talking about doing that on the developer-side, it's tricky due to what can be cloned/transfered |
| 19:31 | <wanderview> | JakeA: once ReadableStream transfer gets spec'd, I think Response/Request objects should be transferable as well? |
| 19:31 | <JakeA> | Agreed |