| 05:55 | <Domenic> | Was following various links and ended up on https://www.w3.org/wiki/IETF_HTML5_Meeting_March_2009 . So interesting to see, considering how things played out. |
| 06:39 | <annevk> | “IETF does not want to do user interface recommendations” and yet HTTP does/did |
| 06:41 | <annevk> | Thanks for finding that |
| 07:15 | <annevk> | Btw, for those not wanting to deal with git much, GitHub Desktop now allows you to submit commits to all PRs (i.e., including non-local) |
| 07:15 | <annevk> | Rebasing or cleaning up commits is still some command line from memory adventure though |
| 08:00 | <hsivonen> | zcorpan: yes, the HTML parser in Gecko waits for 1024 bytes or an encoding declaration (incl. BOM) |
| 08:01 | <annevk> | Ah, and that'll also apply to text/plain and such |
| 08:01 | <annevk> | So if you want to test any kind of streaming there you first have to send 1024 bytes |
| 08:01 | <hsivonen> | hmm. I'm not sure that id does |
| 08:02 | <hsivonen> | if it does, it affect text/plain only as a side effect of sharing code with HTML |
| 08:02 | <annevk> | I guess it doesn't have to in theory at least as the encoding is derived differently (I haven't tested) |
| 08:02 | <hsivonen> | there isn't anything other than the BOM to wait for in the text/plain case |
| 08:03 | <hsivonen> | it's better to just declare charset on the HTTP layer than to pad by 1024 bytes |
| 08:05 | <annevk> | hsivonen: so if I include a BOM or HTTP charset it stops waiting? |
| 08:05 | <annevk> | That'd make sense |
| 08:05 | <hsivonen> | annevk: it doesn't wait in those cases |
| 08:07 | <hsivonen> | on a different topic: Is the Editor's Draft of Unicode public? |
| 08:13 | <annevk> | hsivonen: not that I know, sometimes there's drafts available for technical reports, but even those are not meant to be shared I think |
| 08:14 | <annevk> | I wish someone would make them publish on GitHub and in HTML... |
| 08:15 | <hsivonen> | annevk: OK. I'll ask on the Unicode list to be sure and to express the idea that there's a use case for viewing the Editor's Draft |
| 08:15 | <annevk> | hsivonen: version control of some kind would be great too |
| 08:16 | <hsivonen> | use case being optimizing out feedback that's no longer relevant if already addressed |
| 08:16 | <annevk> | hsivonen: a public issue tracker would also help with that |
| 08:16 | <hsivonen> | yes |
| 08:17 | <annevk> | hsivonen: where you can have some actual dialogue with folks... |
| 08:17 | <hsivonen> | the issue tracking is public but without search or interaction |
| 08:17 | <hsivonen> | anyway, I think I might send feedback on two things: |
| 08:18 | <nox> | gsnedders, jgraham: https://github.com/servo/servo/blob/wptup/tests/wpt/web-platform-tests/tools/wptrunner/wptrunner/environment.py#L145:L149 It seems like 'wss' is lacking there. |
| 08:18 | <hsivonen> | 1) to request informative discussion of alignment issues of reading in UTF-16 or UTF-32 in addition to the current discussion of endianness issues |
| 08:19 | <hsivonen> | 2) to request an informative remark pointing the Encoding Standard and the security principle embodied by the encoding standard when it comes to securely decoding multi-byte legacy encodings in the case where the trail byte of an unmappable pair is in the ASCII range |
| 08:20 | <annevk> | "The state of registerProtocolHandler" there's someone else who cares \o/ |
| 08:20 | annevk | is looking at BlinkOn lightning talks |
| 08:20 | <annevk> | well, slides |
| 08:21 | <annevk> | hsivonen: what do you mean by 1? |
| 08:24 | <hsivonen> | annevk: when ingesting UTF-16 data from a byte-oriented I/O source, you not only need to make sure the endianness is right and that there are no unpaired surrogates. You also need to arrange the data to start from an even memory address |
| 08:25 | <hsivonen> | annevk: that is, UTF-16 and UTF-32 are even worse as on-disk or over-the-network representations than the Unicode Standard suggests |
| 08:27 | <annevk> | hsivonen: I'm afraid I don't understand the "even memory address" bit |
| 08:27 | <hsivonen> | annevk: even as in not odd |
| 08:27 | <hsivonen> | annevk: a memory address whose least significant bit is zero |
| 08:28 | <annevk> | hsivonen: I sorta got that, but I don't understand why |
| 08:30 | <hsivonen> | annevk: many CPU architectures and practically all programming languages require data to be aligned such that if you want to read a 16-bit unit in the usual way, it has to reside on a every-16-bits boundary |
| 08:30 | <hsivonen> | annevk: even where that might not be true for x86, it's true for C (and C++ and Rust) on x86 |
| 08:30 | <annevk> | hsivonen: interesting; if I'm not mistaken the way JavaScript deals with bytes does not require that |
| 08:31 | <hsivonen> | (e.g. the compiler is allowed to autovectorize on that assumption) |
| 08:31 | <annevk> | the offset on the ArrayBuffer on which you create a view can be arbitrary |
| 08:32 | <hsivonen> | annevk: in that case, ArrayBuffer views can't use the default read/write operations from C++ or on some architectures even in the JIT code |
| 08:34 | <annevk> | https://tc39.github.io/ecma262/#sec-typedarray-buffer-byteoffset-length fwiw |
| 08:34 | <annevk> | So instead of a byteOffset a wordOffset or some such would have been a faster design? |
| 08:35 | <annevk> | Anyway, thanks for the lesson 😃 |
| 08:36 | <hsivonen> | annevk: step 7 |
| 08:36 | <hsivonen> | "If offset modulo elementSize ≠ 0, throw a RangeError exception." |
| 08:37 | <hsivonen> | annevk: so unaligned offsets are not allowed |
| 08:37 | <annevk> | oh, thanks for that additional lesson |
| 08:37 | <hsivonen> | the DataView API is suggestive of things being potentially slower than usual array accesses |
| 08:37 | <hsivonen> | annevk: you're welcome |
| 08:38 | <annevk> | I think the main aspect that makes ArrayBuffer slow (or hard to optimize for) is that it can be detached |
| 10:20 | <annevk> | mkwst: you around? |
| 10:20 | <annevk> | mkwst: I'm wondering whether you're gonna do another pass on https://github.com/whatwg/fetch/pull/715 or not |
| 12:26 | <jgraham> | Domenic: /html/browsers/browsing-the-web/scroll-to-fragid/replacement-enabled.html seems to be your test; we are having to disable it in gecko for being flaky |
| 12:32 | <Domenic> | Link to source? I'm on mobile. |
| 12:37 | <Domenic> | Well, file an issue I guess, and we can dig into whether the spec says the test should be nondeterministic, or if it's a Firefox bug. |
| 12:37 | <Ms2ger> | Domenic, https://github.com/w3c/web-platform-tests/blob/master/html/browsers/browsing-the-web/scroll-to-fragid/replacement-enabled.html |
| 12:37 | <jgraham> | Ms2ger: Thanks |
| 12:38 | <jgraham> | Filed an issue |
| 12:38 | <Domenic> | Hmm seems like the issue is the Firefox bug mentioned in the test comment |
| 12:39 | <Domenic> | Maybe just increase from 100 to a larger number |
| 12:40 | <jgraham> | Oh you had a sneaky way of writing setTimeout |
| 12:40 | <jgraham> | OK, that might help. Thanks |
| 13:49 | <annevk> | wanderview: domfarolino: if it helps I can land the same-origin change (and test) |
| 13:50 | <annevk> | wanderview: domfarolino: it seems folks want this to move forward and it seems unlikely it'll break things |
| 13:50 | <wanderview> | annevk: works for me... or I was just going to do the test changes locally and sync up |
| 13:51 | <annevk> | wanderview: which way you prefer? |
| 13:51 | <wanderview> | jgraham: if annevk lands some test changes upstream and I land the same changes in gecko... will we breach the warp core? |
| 13:54 | <jgraham> | wanderview: That is supposed to work these days |
| 13:55 | <wanderview> | cool |
| 13:55 | <wanderview> | annevk: I'd say go ahead and land them then |
| 13:55 | <jgraham> | So hopefully not, but maybe? :) |
| 13:55 | <jgraham> | (go for it, I'll be able to fix if there's a problem) |
| 13:55 | <jgraham> | wanderview: Although I see you haven't looked at the trees today |
| 13:55 | <jgraham> | Landing stuff in Gecko isn't possible :) |
| 13:56 | <wanderview> | jgraham: I guess that makes things easier |
| 13:57 | <wanderview> | jgraham: btw, I don't recall seeing a gecko sync bug for this one? https://github.com/w3c/web-platform-tests/pull/10536 |
| 13:57 | <wanderview> | maybe due to the tree sadness |
| 13:59 | <jgraham> | wanderview: https://bugzilla.mozilla.org/show_bug.cgi?id=1455367 I think? |
| 13:59 | <wanderview> | jgraham: thanks! |
| 13:59 | <wanderview> | jgraham: I see... it hasn't been moved to Core yet, so my search didn't find it |
| 14:00 | <annevk> | Ooh, I had already filed browser bugs too |
| 14:02 | <wanderview> | jgraham: although I'm having trouble finding the test changes in the try build on that bug... |
| 14:04 | <jgraham> | wanderview: I'll check after my meeting. I did notice some odd-looking try messages this morning |
| 14:05 | <wanderview> | thanks |
| 14:05 | annevk | updates Edge and Safari bugs |
| 14:16 | <wanderview> | annevk: if it makes you feel any better the change to same-origin credentials blew up a bunch of internal gecko tests |
| 14:26 | <annevk> | wanderview: makes me sad for you mostly (and a little sad we still have some many non-upstreamed stuff) |
| 14:26 | <annevk> | so much |
| 14:31 | <wanderview> | annevk: its mostly duplicative of the WPT changes |
| 14:34 | <annevk> | wanderview: it's not just worker module scripts btw; it's module scripts in general: https://github.com/whatwg/html/issues/2557 |
| 14:35 | <annevk> | wanderview: I'll see if I can work out the spec changes later today for those |
| 14:35 | <wanderview> | ok |
| 14:35 | <wanderview> | annevk: I don't think we ship modules for a few weeks... probably too far along to fix it before shipping, though |
| 14:36 | <wanderview> | of course, everyone else has already shipped I think |
| 14:37 | <annevk> | wanderview: yeah, as with fetch() I guess the upside will be that more things will work |
| 14:38 | <annevk> | wanderview: and maybe it's better to make the changes separately to measure impact separately (and maybe ensure tests) |
| 14:48 | <annevk> | wanderview: Simpson's GIFs will continue until morale improves |
| 14:48 | <wanderview> | yea... |
| 19:11 | <domfarolino> | annevk: thanks for landing that wpt PR, will get up to date on some of the surrounding stuff soon |
| 19:47 | <wanderview> | domfarolino: thanks for looking at the tests... I had some time so I pushed the change through on the firefox side today |
| 20:22 | <domfarolino> | wanderview: of course. Awesome, will be getting to finishing chrome shortly. |