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
Will look, thanks, it's probably a weird interaction between JSString representation and our utf8 conversion code
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.
I removed the encode() one here hah: https://bugzilla.mozilla.org/show_bug.cgi?id=1607083
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