05:39 | <Ondřej Žára> | So I just reported one of the weirdest bugs I ever encountered: https://bugzilla.mozilla.org/show_bug.cgi?id=1781724 |
05:48 | <sideshowbarker> | In general, Gecko seems to have some fun quirks with string handling.. I have a vague feeling of having seen something very similar to this this bug before |
05:49 | <sideshowbarker> | smaug: emilio: ⬆️ |
06:50 | <emilio> | So I just reported one of the weirdest bugs I ever encountered: https://bugzilla.mozilla.org/show_bug.cgi?id=1781724 |
07:10 | <annevk> | emilio: FWIW, I suspect hsivonen (away from Matrix until 2022-08-08) will be able to identify the cause. He added some fast paths between JS and C++ that I would expect are the cause here. |
07:18 | <emilio> | emilio: FWIW, I suspect hsivonen (away from Matrix until 2022-08-08) will be able to identify the cause. He added some fast paths between JS and C++ that I would expect are the cause here. |
07:18 | <emilio> | Because UTF8String effectively behaved like the manual code |
07:20 | <emilio> | So either a bug in UTF8String, or a pre-existing issue / js engine bug or something. |
07:21 | <emilio> | Tho I think it'll probably have to wait till tomorrow because today I'm away from my laptop unexpectedly (hospital, but nothing bad) |
07:22 | <annevk> | Oh, take care! |
09:24 | <Benjamin Gruenbaum> | Hey, if I have multiple dynamic script tags (dynamic as in created programatically) is their execution order guaranteed? |
10:59 | <Benjamin Gruenbaum> | Found https://web.archive.org/web/20220621024629/https://wiki.whatwg.org/wiki/Dynamic_Script_Execution_Order will read on |
11:04 | <annevk> | Benjamin Gruenbaum: I'd recommend reading the HTML Standard instead, doubt old Wiki pages are accurate, but maybe |
11:05 | <annevk> | Jake Archibald may also have written something about this. As did Peter Beverloo (at the very least created a cool infographic we use in the standard) |
11:06 | <Domenic> | Yeah, the relevant algorithm is going to be "prepare a script element", but I don't know off the top of my head what it says.. |
11:10 | <Benjamin Gruenbaum> | Thanks, will do (I came here because I couldn't find conclusive evidence in the spec but Domenic's hint might be what I was missing) |
11:21 | <Benjamin Gruenbaum> | I think it's "If parser document is non-null and el does not have an async attribute, then set el's force async to true." doing it, anyway I'll dig in - thanks |
11:23 | <Benjamin Gruenbaum> | Wait that's probably not right :D |
11:43 | <Benjamin Gruenbaum> | (here's the crbug https://bugs.chromium.org/p/chromium/issues/detail?id=594444#c16 though I'm still not sure if I'm misunderstanding the spec or browsers just all ignore the spec - probably the former) |
11:46 | <Benjamin Gruenbaum> | So, it turns out it just marks scripts with createElement with async=true , you can still mark them as async=false :D |
11:46 | <Benjamin Gruenbaum> | Thanks again everyone |
13:15 | <Jake Archibald> | Can algorithm prose reference this inside queued/parallel steps? Basically, is it like function () {} or () => {} in JavaScript? 😀 |
13:20 | <Ms2ger 💉💉> | I think no |
13:21 | <Jake Archibald> | That was my thought too, but didn't know if I was being overly strict. It might be nice to allow it, but it doesn't seem like it's currently allowed. |
13:21 | <Domenic> | I think closing over this is fine |
13:21 | <Domenic> | Well, OK, except in-parallel you should be careful about referencing Web IDL objects |
13:21 | <Jake Archibald> | Of course |
13:31 | <Jake Archibald> | Filed https://github.com/whatwg/webidl/issues/1175 in case it's worth putting in the spec |