| 00:04 | <nbenner> | ondras: I think the accepted way to do that is to check for side effects. If the script you're attempting to check defines an object (lets say foo) and you don't know if that file has loaded yet, check to see if foo exists on the page. if it does then the script is probably done executing, or at least has yielded control... |
| 07:27 | <ondras> | nbenner: ok thanks |
| 14:58 | <domfarolino> | What's an easy way to call fetch() and have the promise resolve to a response whose type is "error" (things like 404 / CORS failures don't give me what I want) |
| 15:22 | <Domenic> | domfarolino: fetch("bad-url:bad") |
| 15:23 | <domfarolino> | Domenic: That seems to just reject the promise though, instead of resolve with an error response right? |
| 15:23 | <Domenic> | domfarolino: network errors always reject the promise |
| 15:23 | <domfarolino> | I see, that's what I wasn't sure about |
| 15:23 | <Domenic> | Gotcha |
| 15:24 | <domfarolino> | Domenic: OK so it's impossible to assert (request.type == error) in a fetch() then handler? |
| 15:24 | <Domenic> | Yeah |
| 15:24 | <domfarolino> | Cool ty |
| 15:24 | <Domenic> | I guess type === error is only possible for manually-constructed responses |
| 15:24 | <domfarolino> | Ah, yeah "If response is a network error, then reject p with a TypeError and terminate these substeps." |
| 15:24 | <domfarolino> | Domenic: right |
| 15:25 | <domfarolino> | Response.error() for example |
| 16:16 | <jugglinmike> | Anyone here familiar with Cross-Origin Opener Policy? I'm having some trouble understanding a document from a Chromium dev https://docs.google.com/document/d/1zWqwI8PFrezwQpBSejIMUfdtsIYl9-h8epasdrDXVIM |
| 16:39 | <Domenic> | annevk: double-check me... shared/service worker agents are not owned by anything in the spec? They're just allocated and kind of float freely? |
| 16:39 | <Domenic> | s/agents/agent clusters |
| 17:24 | <annevk> | Domenic: yeah, technically the user agent needs some kind of lookup table |
| 17:25 | <annevk> | Domenic: but they are directly owned by the user agent |
| 17:25 | <annevk> | although their lifetime is impacted by "related" browsing sessions closing |
| 17:26 | <annevk> | or documents/window agents I guess, not so much browsing sessions |
| 17:46 | <Domenic> | OK cool, that's about what I thought. I guess nailing that down would be a bit of a pain so leaving things as-is is OK. |
| 17:47 | <annevk> | Domenic: we have a lot of things today that'll make it easier to do once there's a stronger need |
| 17:48 | <annevk> | I think the more problematic thing with workers is that we establish an environment before we fetch |
| 20:36 | <jugglinmike> | Domenic: I'm a bit confused about the intention for SharedArrayBuffer and COOP/COEP |
| 20:37 | <jugglinmike> | I used to think SAB was to be exposed always but only allowed for transfer in crossOriginIsolated contexts |
| 20:37 | <jugglinmike> | Like here https://github.com/whatwg/html/pull/4734 |
| 20:38 | <jugglinmike> | But I've recently read things that suggest that SAB will simply not be available outside of crossOriginIsolated contexts |
| 20:38 | <jugglinmike> | like here https://web.dev/why-coop-coep/ |
| 20:42 | <jugglinmike> | That second source is more recent and matches Firefox's current behavior |
| 20:43 | <jugglinmike> | But work is proceeding on the first |
| 20:45 | <jugglinmike> | Ah |
| 20:45 | <jugglinmike> | "SharedArrayBuffer objects are in principle always available, but unfortunately the constructor on the global object is hidden, unless the two headers mentioned above are set, for compatibility with web content. There is hope that this restriction can be removed in the future. WebAssembly.Memory can still be used to get an instance." |
| 20:46 | <jugglinmike> | via https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer/Planned_changes |
| 20:48 | <jugglinmike> | So I guess the web.dev post is technically inaccurate, but explaining the distinction is unlikely to help anyone |
| 20:57 | <Domenic> | Right, it kind of depends on whether you're talking about SharedArrayBuffer, or "shared array buffers" |
| 21:01 | <jugglinmike> | ah, yeah, that's subtle |
| 21:02 | <jugglinmike> | This one uses the term "threaded SharedArrayBuffer" https://docs.google.com/document/d/1zDlfvfTJ_9e8Jdc8ehuV4zMEu9ySMCiTGMS9y0GU92k/edit# |
| 21:04 | <jugglinmike> | "SharedArrayBuffer sharing" would likely raise some eyebrows |
| 21:07 | <jugglinmike> | Stage 0 proposal: "Rename SharedArrayBuffer to PotentiallyShareableArrayBuffer" |