| 04:12 | <domfarolino> | The "await a stable state" dfn in HTML mentions "When an algorithm running in parallel is .....". However, when we use "await a stable state" in https://html.spec.whatwg.org/multipage/images.html#updating-the-image-data, that algorithm is not running in parallel at that time right? |
| 04:15 | <domfarolino> | Seems like we're running "synchronously" on the "main thread", and then we queue a microtask to simply resume the algorithm's "synchronous steps" later, before going in parallel in step 23 |
| 07:20 | <annevk> | domfarolino: update the image data is not always invoked synchronously necessarily, though it's really too vague |
| 07:21 | <annevk> | domfarolino: that is, "A user agent that obtains images on demand must update the image data of an img element whenever it needs the image data" could be a thing the compositor thread invokes I suppose? |
| 07:21 | <annevk> | domfarolino: (not that the spec defines a compositor) |
| 07:21 | <domfarolino> | yikes. i see i see |
| 07:25 | <annevk> | domfarolino: there's a lot of "topic: img" and it could really do with refactoring... |
| 07:26 | <annevk> | domfarolino: as with other parts of the HTML spec figuring out fact from fiction is the annoying bit |
| 07:28 | <domfarolino> | annevk: hah, that's the impression I get too. makes me want to do something like a feature freeze and a huge rewrite, but ya know, time... |
| 07:29 | <annevk> | domfarolino: feature freeze would give us time |
| 07:30 | <domfarolino> | this is true |
| 09:43 | <annevk> | JakeA: so "run module script" does script + microtasks |
| 09:44 | <annevk> | JakeA: so if you race the return value of run module script with the equivalent of Promise.resolve().then(), would that work? |
| 09:45 | <annevk> | JakeA: and reject if the evaluationPromise is not fulfilled by then |
| 09:49 | <JakeA> | annevk: By the time our algorithm gets evaluationPromise, any microtasks will already have been processed, right? |
| 09:50 | <JakeA> | So if it's "pending", that means it has a top-level await that wasn't simply a microtask |
| 09:51 | <annevk> | JakeA: from what you're telling me that sounds correct, I haven't checked myself |
| 09:51 | <annevk> | JakeA: I guess my suggestion would only aid in not checking internal state in that case, but we could spell the equivalency out in a note I suppose |
| 09:52 | <annevk> | JakeA: the main problem with checking internal state that I see is that JS is more often refactored than you'd think |
| 09:56 | <JakeA> | annevk: All we need is a way to query if the script has 'evaluated' (or whatever it's called in a post top-level-await world). But yeah, problematic if that property moves around. |
| 12:18 | <zcorpan_> | MikeSmith: thanks for the rapid fix! But can you please avoid mentioning folks in commit messages? it can cause useless notification (especially if there are forks) |
| 12:36 | <annevk> | GitHub should just stop supporting that at this point |
| 14:15 | <nox> | annevk: Wishful thinking :P |
| 20:54 | <MikeSmith> | JakeA: so about the problem in the SW+WebView question https://stackoverflow.com/questions/56719340/fetch-request-immediately-failing-in-service-worker-running-through-android-we, it turned out to be a bug https://bugs.chromium.org/p/chromium/issues/detail?id=977784 |
| 20:56 | <MikeSmith> | already fixed in 76 |
| 21:16 | <JakeA> | MikeSmith: yes! I only found out later today too. I wonder why I couldn't recreate it |
| 21:46 | <MikeSmith> | JakeA: dunno but reading through the bug comments, seems like maybe thereare some additional conditions needed to reproduce |