| 01:27 | <MikeSmith> | annevk: I edited https://wiki.developer.mozilla.org/en-US/docs/Web/API/ProcessingInstruction to add a link to the DOM spec |
| 01:27 | <MikeSmith> | ...and to re-work the content to have it actually make sense |
| 01:27 | <MikeSmith> | https://wiki.developer.mozilla.org/en-US/docs/Web/API/ProcessingInstruction$compare?to=1594758&from=1522738 |
| 01:28 | <MikeSmith> | the anno for it will be added/picked-up the next time I run the scripts that (re)generate the https://raw.githubusercontent.com/w3c/mdn-spec-links/master/dom.json file |
| 04:57 | <Domenic> | MikeSmith: I really like the <hr>s in the generated annotations |
| 05:05 | <MikeSmith> | Domenic: yeah I think there have always been too many browsers in those annotations (the Can I Use and MDN ones in the HTML spec, the Bikeshed-generated ones) to not have them logically separated somehow |
| 06:31 | <MikeSmith> | why/how would an element in the DOM end up with no parentNode? |
| 06:32 | <MikeSmith> | rather, I mean an event target |
| 06:33 | <MikeSmith> | how would event target end up with no parentNode? |
| 06:34 | <MikeSmith> | if you look at https://serviceworkerspec.herokuapp.com/docs/ and inspect the "Collapse Sidebar" arrow/button |
| 06:34 | <MikeSmith> | ... and if you set a click event listener, and check the event target for when that "Collapse Sidebar" arrow/button is clicked |
| 06:38 | <MikeSmith> | ... you will find that it’s either the span whose text content is "Collapse Sidebar" or else the span[aria-hidden] element with the arrow |
| 06:38 | <MikeSmith> | ... and if you inspect those, you find they have no parentNode |
| 06:39 | <MikeSmith> | ... despite them being children of the a[#toc-toggle] element |
| 06:46 | <MikeSmith> | ah, I think I see now: those nodes are getting removed from the DOM by another listener |
| 06:47 | <annevk> | MikeSmith: that sounds very strange. Is there a library involved? Ah |
| 06:47 | <MikeSmith> | annevk: https://www.w3.org/scripts/TR/2016/fixup.js is what does that ToC collapsing |
| 06:48 | <MikeSmith> | I guess I have to look at .composedPath() in this case |
| 06:48 | <MikeSmith> | ... because I don’t see where it would otherwise be exposed at that point |
| 07:47 | <hsivonen> | jgraham: is there a way to tell WPT testharness.js that the test will renavigate before onload fires and, therefore, unload is not an error? |
| 07:48 | <hsivonen> | jgraham: use case: encoding tests where the encoding is discovered after 1024 bytes |
| 08:30 | <annevk> | hsivonen: can you run it in a popup? |
| 08:34 | <hsivonen> | annevk: Maybe. I'll fix other things first. (Obviously, non-UTF-8 tests are hard to edit, so I'll need to figure out a way to edit them without corrupting the tests.) |
| 08:37 | <annevk> | hsivonen: I quite like Hex Fiend, though it's mainly useful if you have the bulk of the test already written |
| 08:38 | <hsivonen> | these are already written |
| 08:46 | <JakeA> | I'm getting spammed with "Run failed for master (ccf3169)" on my fork of web-platform-tests. How do I make it stop? |
| 08:47 | <hsivonen> | in other news, various test cases that have undeclared UTF-8 seem to want windows-1252 specifically, so one needs to detect the UTF-8 and then respond windows-1252 instead of just allowing whatever the outcome would be from excluding UTF-8 from detection |
| 08:48 | <hsivonen> | (both intentional and addidental tests) |
| 08:49 | <hsivonen> | argh. accidental |
| 08:49 | <hsivonen> | accidental tests include things like not declaring the encoding but copying and pasting smart quotes from the spec into a comment in the test |
| 08:49 | <hsivonen> | in a UTF-8 editor |
| 08:53 | <annevk> | JakeA: W3C IRC, #testing might be a better place |
| 08:53 | <annevk> | JakeA: if you haven't rebased in a while, that's usually a good bet btw |
| 08:53 | <JakeA> | ta. Nah, it started when I rebased :D |
| 08:54 | <annevk> | good times |
| 08:54 | <annevk> | hsivonen: that doesn't sound like fun to have to debug at all |
| 09:04 | <annevk> | mkwst: why did https://bugs.chromium.org/p/chromium/issues/detail?id=691930 stall? |
| 09:04 | <annevk> | mkwst: the localhost thing |
| 09:05 | <mkwst> | Hrm. It's implemented. Let me find the patch and close that bug. |
| 09:05 | <annevk> | mkwst: even if "Let 'localhost' be localhost." is not standardized, applications are still permitted to always use the loopback address, right? |
| 09:05 | <annevk> | mkwst: ah okay, for all .localhost. addresses? I guess that means Firefox could follow |
| 09:06 | <mkwst> | annevk: I don't recall that detail. Let me find the patches so I don't lie to you. :) |
| 09:06 | <annevk> | ta! |
| 09:08 | <mkwst> | annevk: https://chromium-review.googlesource.com/c/chromium/src/+/598068/ |
| 09:08 | <mkwst> | Tests say that we do indeed resolve `*.localhost` to loopback (both ipv4 and ipv6). |
| 09:09 | <annevk> | mkwst: great, thanks! |
| 09:11 | <mkwst> | annevk: I gave up on getting it through DNSOP. :( |
| 09:12 | <annevk> | mkwst: we could put it in Fetch still, adding a comment to standards-positions atm |
| 09:13 | <mkwst> | In "obtain a connection"? That's pretty hand-wavey as-is, and I don't think anyone has the energy to make it less so. |
| 09:14 | <annevk> | Fair |
| 09:14 | <mkwst> | Could add a note, I guess? I'm not sure how we'd add a normative requirement there, given that DNS isn't really described at all. |
| 09:16 | <annevk> | We could add more hand-wavy things about what obtaining a connection involves and make that part normative |
| 09:16 | <annevk> | But doesn't seem super important |
| 09:16 | <mkwst> | Yup. And yup. |
| 09:16 | <annevk> | I'm not sure if we still support that eager DNS lookup feature, defining that would also want some kind of hook |
| 09:17 | <mkwst> | Happily(?), there is always more work to do. |
| 09:23 | <hsivonen> | annevk: fortunately, it didn't require debugging |
| 09:46 | <jgraham> | hsivonen: No for tests that do weird navigation things you need to use a popup |
| 09:46 | <jgraham> | Unfortunately |
| 09:49 | <hsivonen> | jgraham: can you suggest an example that I should look at? |
| 09:57 | <jgraham> | hsivonen: Not off the top of my head, will look in a bit when I'm not on a rather crowded train |
| 09:58 | <hsivonen> | jgraham: ok. thanks. |
| 09:58 | <hsivonen> | jgraham: is adding a setup() argument allow_unload out of the question? |
| 09:59 | <jgraham> | hsivonen: I suspect it interferes too much with the way that the testdriver bits work |
| 09:59 | <hsivonen> | jgraham: ok. :-( |
| 09:59 | <jgraham> | So we'd need some way to communicate that a specific test wasn't using testdriver and then more codepaths and complexity |
| 10:34 | <annevk> | hsivonen: I’d make the popup message the results to the opener once done, that’s easiest |
| 10:35 | <annevk> | hsivonen: if you grep for window.open you’ll find some examples; if that doesn’t help let me know and I’ll create an example |
| 10:35 | <jgraham> | hsivonen: Right so https://searchfox.org/mozilla-central/source/testing/web-platform/tests/html/browsers/browsing-the-web/unloading-documents/001.html is a somewhat old example that uses the properties of the opener directly |
| 10:36 | <jgraham> | But as annevk says, using postMessage to return the results is probably better |
| 10:38 | <jgraham> | https://searchfox.org/mozilla-central/source/testing/web-platform/tests/content-security-policy/unsafe-hashes/javascript_src_denied_missing_unsafe_hashes-window_location.html is a pretty simple example of that |
| 10:38 | <jgraham> | (I guess there are bonus points if you do things like forward onerror to the parent) |
| 11:09 | <MikeSmith> | PSA: If you ever run any scripts that make requests to https://tools.ietf.org/, make sure the requests are sent with a User-Agent header; otherwise your IP address will get blocked for 7 days. |
| 11:10 | <MikeSmith> | ... and apparently, urllib3 doesn’t send a User-Agent header in requests https://github.com/urllib3/urllib3/issues/1296 |
| 11:18 | <hsivonen> | jgraham, annevk: thanks |
| 17:08 | <annevk> | Domenic: so afaict there's multiple numbers in use for the same email on lists.whatwg.org |
| 17:09 | <annevk> | Domenic: e.g., http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019595.html and http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/061868.html are identical, just accessed from a different index |
| 17:09 | <Domenic> | Oh... fun? |
| 17:09 | <annevk> | (it's https://lists.w3.org/Archives/Public/public-whatwg-archive/2009May/0030.html) |
| 17:10 | <Domenic> | I bet if we knew the logic behind it, we could still figure that out, since they still seem date-sequential. But I'm not sure how to. |
| 17:10 | <annevk> | I do continue to get the same email if I increment both numbers |
| 17:11 | <annevk> | So the numbers are not related to the type of index |
| 19:05 | <Krinkle> | Does someone here know of a more public / official-looking signal from Mozilla of their intent to cap cookies to 7 days? |
| 19:05 | <Krinkle> | I found https://groups.google.com/forum/m/#!topic/mozilla.dev.platform/lECBPeiGTy4 and https://bugzilla.mozilla.org/show_bug.cgi?id=1529836 but both seem a bit internal / non-representative. |
| 19:55 | <annevk> | Krinkle: for document.cookie? If Ehsan is involved that seems official |
| 19:55 | <annevk> | Krinkle: Safari does a similar thing iirc |
| 19:58 | <Krinkle> | yeah, apple talked about it very clearly on their blog |
| 19:58 | <Krinkle> | I'm looking for something less obscure than an engineering ticket or obscure mailing list :) |
| 20:17 | <annevk> | Krinkle: you prolly know how to get hold of Ehsan |
| 20:18 | <Krinkle> | Ha, hadn't thought of that. Thanks :) |
| 20:18 | <annevk> | Krinkle: he might be able to make things look more official if there’s a need |
| 20:18 | <Krinkle> | yeah |