| 00:01 | <MikeSmith> | OK, well I know he got pretty frustrated with it more than once |
| 00:01 | <MikeSmith> | dunno why that group has the kind of culture it does |
| 00:02 | <MikeSmith> | I don’t follow it myself but I did see bz’s comments, which seemed to indicate the specs there were being edited without the kind of attention to deal and rigor that should be expected |
| 00:03 | <MikeSmith> | railgun: would be nice to have something set up to do the bumping described there. I vaguely recall other repos that have something set up like that |
| 01:18 | <railgun> | MikeSmith: I know some projects like Zulip have a claim bot (e.g. https://github.com/zulip/zulip/issues/8279) but I'm personally not a fan of it |
| 01:21 | <MikeSmith> | railgun: OK. So rather than a bit did you have in mind that somebody will instead periodically do the re-triaging manually? |
| 01:24 | <railgun> | I'd like a human reponse to issues that need to be bumped instead of a bot |
| 01:24 | <railgun> | but some form of automation could still be done with the GitHub api? |
| 01:25 | <railgun> | such as curate a page of good first issues that haven't been active in a while |
| 01:27 | <railgun> | I'm not familiar with the word triaging, care to explain it to me? |
| 01:41 | <railgun> | MikeSmith: for automation I'm thinking of this: run a script each day, for all open good first issues, if last action > X days ago (i.e. the issue is inactive) then add it to the list of issues to manually review |
| 02:41 | <MikeSmith> | railgun: ok yeah that could work |
| 02:43 | <MikeSmith> | by triaging I just meant somebody going (back) through the issues and deciding what to do with them ー (re)categorizing or (re)labeling etc |
| 03:08 | <railgun> | ok thanks |
| 08:44 | <annevk> | JakeA: great talk on event loops; would have loved to see microtasks as part of the animation |
| 08:45 | <annevk> | JakeA: also makes me wonder again about event listeners and if they are the only place with the gotcha and whether we should consider switching |
| 08:47 | <JakeA> | annevk: Cheers! I don't think microtasks fit as part of the animation, since they don't happen in one place. That's why I did the separate stack animation to show how the microtask queue is emptied vs other queues |
| 08:49 | <JakeA> | Although there's a microtask checkpoint in the event loop, I figured it'd confuse things to put it on the diagram, since the most likely place folks will encounter microtasks is on-stack-empty |
| 08:50 | <JakeA> | annevk: What change are you thinking of for events? Running microtasks after callbacks is what allows IDB to be promisified, so I'm pretty keen on that 😀 |
| 08:50 | <annevk> | JakeA: always running them at end of listener |
| 08:51 | <annevk> | JakeA: not sure if empty stack is exposed in other ways though |
| 08:52 | <JakeA> | annevk: ohh I see. Interesting. It would become the only point where promises can run in the middle of other JS, which may become weird |
| 08:53 | <annevk> | JakeA: do microtasks run after rAF? |
| 08:53 | <annevk> | I guess they have to? |
| 08:53 | <JakeA> | yeah |
| 08:54 | <annevk> | Would have been complicated to fit into the animation then, indeed |
| 08:55 | <JakeA> | They can also happen in events that happen in the render steps. Eg scroll, resize, animationend, touchmove, intersection observers etc etc |
| 08:56 | <JakeA> | I wanted to cover those kind of events, but ran out of time |
| 09:02 | <annevk> | JakeA: contentDocument does not throw for cross-origin frames I think |
| 09:02 | <annevk> | JakeA: should return null iirc |
| 09:03 | <JakeA> | annevk: ahh gotcha. So the error is when accessing 'body' of null, rather than a security error. |
| 09:04 | <annevk> | JakeA: yeah; contentWindow.document throws a sec error |
| 09:10 | <annevk> | JakeA: what might work is zooming in on the task/rAF/render event when you get there to show the microtasks in action |
| 10:33 | <AutomatedTester> | what does it mean to have a navigation mature? does it mean complete? |
| 10:39 | <JakeA> | annevk: it's still tough, because you can have multiple microtask checkpoints in a task, or in raf. Microtasks just feel more to do with JS execution than the 'loop'. |
| 11:20 | <MikeSmith> | I can’t recall ever having heard the term “navigation nature” |
| 11:20 | <MikeSmith> | at least don’t think it’s used in the HTML spec |
| 12:29 | <annevk> | mature is a thing |
| 12:29 | <annevk> | It’s some kind of point of nu return |
| 15:10 | <bradleymeck> | URL.createObjectURL is in the File API spec... which makes it awkward, but would it be the right place to try and add a form that takes a Response? That seems counter intuitive to me |
| 15:20 | <Domenic> | Object URLs are probably not going to be updated much, as they're leaky and we're trying to get the platform away from them... But you don't need to add to do that, just do URL.createObjectURL(await response.blob()) |
| 15:26 | <bradleymeck> | Domenic: that doesn't let me have non-200 responses and the like be created |
| 15:27 | <Domenic> | Yeah, blob URL resolution always succeeds |
| 15:27 | <bradleymeck> | I'm fine using a new API that gives me ~= ability to create these synthetic URLs |
| 15:27 | <Domenic> | If you want a non-200 response, use Response |
| 15:27 | <Domenic> | That's where the platform is moving |
| 15:27 | <bradleymeck> | Domenic: I still need to generate a URL string for ESM |
| 15:27 | <bradleymeck> | and window.caches doesn't seem to let me do that |
| 15:27 | <Domenic> | All I can say is, trying to use an effectively-deprecated technology as a key part of your workflow seems like a bad idea. |
| 15:28 | <bradleymeck> | Domenic: is there an alternative? |
| 15:28 | <Domenic> | Not sure what the context is, but using Response is generally what is preferred |
| 15:28 | <bradleymeck> | I need to make a URL for ESM to import based upon a Response |
| 15:29 | <wanderview> | JakeA: are you ok with this ready promise behavior from a webdev perspective? mainly curious because I'm about to re-write our ready promise stuff and just want to know if there is any chance we would change it... https://github.com/w3c/ServiceWorker/issues/1279 |
| 15:29 | <Domenic> | OK, well, that's probably not going to be possible on the web platform, because indirecting through URLs has proven very problematic and leaky. |
| 15:29 | <bradleymeck> | Domenic: right, for web I'm having to do multiple round trips through service workers |
| 15:30 | <bradleymeck> | I'd love to read the exact problems of synthetic URLs sometime if it is written up in a single place |
| 15:31 | <Domenic> | Essentially they leak memory forever |
| 15:31 | <Domenic> | The fact that blob URL scope is very wide is also problematic. |
| 15:31 | <Domenic> | (Not sure how wide, but possibly larger than a single process.) |
| 15:31 | <bradleymeck> | ESM Module Map does too? |
| 15:31 | <Domenic> | No, you can throw away the contents of the source text of a module once it's compiled. (Modulo f.p.toString issues.) |
| 15:32 | <Domenic> | And you can definitely throw it away after the realm gets destroyed (e.g. by navigation) |
| 15:32 | <wanderview> | FWIW I would much rather see `.src` or `.srcobj` take a Response vs making URLs out of a Response |
| 15:32 | <Domenic> | Neither is true for blob URLs |
| 15:32 | <Domenic> | +1 wanderview |
| 15:32 | <bradleymeck> | wanderview: but JS needs a string not a reference |
| 15:34 | <wanderview> | bradleymeck: sorry, what is the use case that requires a string? |
| 15:34 | <bradleymeck> | wanderview: `import "..."` |
| 15:38 | <wanderview> | I guess I'd rather see discussion on how to pass a consumable response into `import` vs converting Response objects into memory-locked buffers that get leaked |
| 15:38 | <bradleymeck> | wanderview: well that is in the JS spec so I'm not sure what you want to discuss |
| 15:39 | <bradleymeck> | it is done at parse time so you can't really grab references |
| 15:39 | <bradleymeck> | If a different store works, that seems fine too. I just didn't see how to do this workflow with `window.caches` |
| 15:41 | <bradleymeck> | it seems like the main objection is that blob URLs are shared across realms and don't free up once used? |
| 15:41 | <wanderview> | bradleymeck: you have to explicitly call revokeObjectURL() if you want to free the blob URL before the window/worker that created them goes away |
| 15:42 | <bradleymeck> | wanderview: would standardizing https://msdn.microsoft.com/zh-cn/data/hh772302(v=vs.100) 's oneTimeOnly make sense then? |
| 15:42 | <wanderview> | bradleymeck: that would create a page that could not be reloaded then, right? |
| 15:44 | <bradleymeck> | wanderview: I've never considered directly navigating to a blob URL as the main window, but yes. I think for all these solutions of "don't keep the URL alive" that is true, same for Object references like Response which would need to be reloaded somehow |
| 15:49 | <bradleymeck> | blob URLs should be revoked also when their document is unloaded now so don't think they would let you reload anyway https://w3c.github.io/FileAPI/#lifeTime |
| 15:51 | <wanderview> | correct |
| 15:52 | <Domenic> | domfarolino: https://github.com/whatwg/console/issues/82 and https://github.com/whatwg/console/issues/110 can probably be closed |
| 15:53 | <bradleymeck> | I guess `location = Response` could in theory keep that response body alive? but then you could do `location = new Response(await fetch(blob)...)` to make shallow reloading of blob URLs work too |
| 15:54 | <domfarolino> | Domenic: That sounds good thanks. I should also be able to close https://github.com/whatwg/console/issues/27 today |
| 15:54 | <Domenic> | Oh yeah, that'll be quite good :) |
| 15:56 | <Domenic> | domfarolino: did you see https://twitter.com/TheLarkInn/status/962465510137872385 BTW? Quite exciting; hopefully he'll chime in on various issues. |
| 15:58 | <wanderview> | yoav: what happens if a site tries to preload very large resources or too many resources? do webkit/chromium spill to disk or just stop preload caching at some memory limit? |
| 15:59 | <domfarolino> | Domenic: Oh nice! I remember seeing he joined Edge Developer Tools and was wondering if he'd get a chance to dig around in the Console Spec stuff. Good stuff |
| 16:03 | <bradleymeck> | Domenic: since blob URL lifetimes are limited to the document and we could implement/standardize oneTimeOnly are there any other potential problems you see? |
| 16:03 | <Domenic> | They aren't limited to the document |
| 16:04 | <bradleymeck> | Domenic: other documents can load the URLs, but they get revoked/removed when the origin document is unloaded |
| 16:04 | <Domenic> | Ah really, that's nice |
| 16:04 | <bradleymeck> | so, maybe have a flag to limit their scope to a single realm as well? |
| 16:05 | <Domenic> | Yeah I mean you could keep piling kludges on top, not sure if people will be interested in implementing them, but I guess it's not a lost cause at least. |
| 16:06 | <bradleymeck> | I'm coming at this not from web implementor perspective so I'm already in an awkward scenario |
| 16:06 | <bradleymeck> | anyway, I'll take those flags as being requested and take it to the File API issue tracker for better or worse |
| 16:14 | <domfarolino> | Domenic: We definitely want to close https://github.com/whatwg/console/issues/110 right, like you mentioned? I ask because though the webappsec-csp issue has not been closed yet, https://github.com/w3c/webappsec-csp/issues/217#issuecomment-302474980 kind of does it for me, and it seems that the granular control of console filtering is not part of the CSP. Just want to make sure closing it isn't jumping the gun :) |
| 16:15 | <Domenic> | Yeah I mean you could even say something equivocal like "thanks for letting us know, seems like there's nothing to do on our side". |
| 16:15 | <Domenic> | I basically tried to look through the issue tracker with the POV of Edge implementing and that stood out as not useful to be tracking. |
| 16:24 | <domfarolino> | Ok that makes sense. |
| 16:28 | <jyasskin> | bradleymeck: I haven't thought this through, but might it work to have JS initiate module parsing with a set of either pre-imports or a mapping of import names -> Responses? |
| 16:29 | <bradleymeck> | jyasskin: how would that be different from URLs? |
| 16:32 | <jyasskin> | Oh, actually, that's probably just spelled as a way to pre-fill the module map. I guess it's URLs instead of strings, but they're scoped more tightly than Object URLs. |
| 16:33 | <bradleymeck> | jyasskin: I'm not entirely sure how that would work to make it tighter because you would need to pre populate all the mappings of the whole ESM graph |
| 16:34 | <bradleymeck> | jyasskin: that might be better served by https://github.com/whatwg/html/issues/2640 which I think has stalled (forever?) |
| 16:36 | <yoav> | wanderview: not afaik. preloads are treated like any other subresource (based on their `as` values) |
| 16:36 | <jyasskin> | bradleymeck: Yep, #2640 seems very similar. |
| 16:37 | <wanderview> | yoav: what does that mean? webkit and chromium use RAM without bound if there are excessive <link rel=preload> elements? |
| 16:37 | <yoav> | similar to what happens when there are excessive <img> elements |
| 16:37 | <yoav> | if there are limits in place, they are identical to both |
| 16:38 | <yoav> | The memory cache in both doesn't store a copy of the resources, it holds a pointer to the resources themselves |
| 16:39 | <yoav> | which are in memory for the lifetime of the page |
| 16:58 | <Domenic> | It seems like there are many ways to make a browser use unbounded RAM |
| 17:07 | <wanderview> | yoav: image cache is spec'd as "may" I believe... its an optional optimization... is <link rel="preload"> also something that the browser can just choose to ignore? |
| 17:07 | <wanderview> | Domenic: sure, but for compat reasons it would be nice to know what this under-spec'd feature considers reasonable memory usage |
| 17:18 | <yoav> | wanderview: it's not currently defined. You can open an issue on the spec and we can discuss it there |
| 17:22 | <wanderview> | yoav: sure: https://github.com/w3c/preload/issues/121 |
| 17:25 | <Domenic> | I think image cache is a must, because the web depends on it? |
| 17:25 | <Domenic> | Well, OK, no |
| 17:26 | <Domenic> | There is a lot of wiggle room that makes it effectively a "may", e.g. UAs can remove entries from the list at any time. |
| 22:05 | <domfarolino> | Domenic: Does me interning for Microsoft at all affect my participant agreement? Will I need to sign for an Entity as opposed to sign as a Individual? |
| 22:07 | <Domenic> | domfarolino: oh, hmm, I think it does :-/. But, Microsoft is already signed up, so you should be OK... we'll want to talk to them about getting console added to https://github.com/whatwg/participant-data/blob/master/entities.json#L84-L89 though. |
| 22:07 | <Domenic> | Maybe email the two folks listed as contacts there to explain what's up? |
| 22:46 | <domfarolino> | Domenic: Thanks, will do |