| 04:58 | <annevk> | PiersW: having now read the post, it’s humbling to see you ran into the unsolved script insertion issue. Maybe it’s time to give that another go |
| 07:12 | <jochen__> | CSS and modules load subresources differently, e.g., https://github.com/w3c/webappsec-referrer-policy/issues/123 |
| 07:12 | <jochen__> | it would be cool if they behaved the same :) |
| 07:12 | <jochen__> | any opinion on changing css or modules? |
| 07:18 | <annevk> | jochen__: suspect modules is more compatible, I also thought we made them behave similar already |
| 07:23 | <jochen__> | so the exact difference is that if a stylesheet loads a resource (e.g. an image), the stylesheet itself will be the referrer |
| 07:24 | <jochen__> | and for modules, always the fetch client will be the referrer (and a module itself is not a new fetch client, so the referrer always stays e.g. the document that initiated the module loading) |
| 08:41 | <annevk> | jochen__: ooh, I thought we would not do that, hmm; hopefully Domenic knows the rationale as I’m pretty sure this was discussed |
| 08:48 | <PiersW> | Yeah, scripts are a pain. It's not clear to me what happens if you append a tree with two scripts and the first one removes the second before it's executed. |
| 08:50 | <PiersW> | annevk: The stuff in the blog was about our internal flags, which was really an implementation bug. |
| 09:10 | <annevk> | PiersW: there's a couple open issues on that and I created a bunch of tests, but no cross-browser decision on what it should be |
| 09:10 | <annevk> | (nox also did a bunch of work on that) |
| 09:18 | <nox> | PiersW: https://github.com/whatwg/dom/pull/732 was an attempt at clarifying what happens with DOM mutations and script insertion. |
| 09:19 | <nox> | Unfortunately, other yaks had to be taken care of before I could finish. |
| 09:24 | <PiersW> | Looks thorough. I'll take a look. |
| 09:25 | <PiersW> | I wouldn't say it's the most pressing issue, though, unless we find a site that doesn't like our existing behaviour. |
| 15:31 | <Domenic> | jochen__: annevk: the referrer is set to the module's URL. https://html.spec.whatwg.org/multipage/webappapis.html#fetch-the-descendants-of-a-module-script step 8 passes the module's URL (= base URL) as the referrer to https://html.spec.whatwg.org/multipage/webappapis.html#fetch-a-single-module-script . |
| 17:14 | <annevk> | Domenic: ty |
| 17:34 | <annevk> | Domenic: also, something to think about, there is some appetite to make origin isolation part of COOP+COEP. Making that change how keying works for the entire BCG they end up creating. As everyone has to opt-in, it’s pretty reasonable I think. |
| 17:36 | <Domenic> | annevk: please loop me in to any such discussions. I thought when I went through this previously they were pretty orthogonal and it ended up being not very workable, but I might be wrong. |
| 17:40 | <annevk> | Domenic: it was in person, but I’ll definitely follow up with more detail next week |
| 17:41 | <annevk> | I think it works, main question is whether sites need same-site SAB still |
| 18:52 | <domfarolino> | annevk: jochen__: Hmm did I miss something? I think jochen's comment described the opposite behavior; CSS subresources' referrer is always the node document's URL, and Domenic pointed out (what issue #123 mentions) that the module script becomes the referrer for its descendants |
| 18:53 | <annevk> | domfarolino: for CSS it's the style sheet's URL |
| 18:54 | <domfarolino> | annevk: Interesting. Doesn't https://w3c.github.io/webappsec-referrer-policy/#integration-with-css describe the referrer as the node document's URL? |
| 18:54 | <domfarolino> | Oof nevermind, I think I skipped a step when reading it |
| 18:55 | <annevk> | domfarolino: yeah, step 1 there is pretty clear |
| 18:55 | <domfarolino> | So module script and CSS subresource referrer behavior does match I think |
| 18:56 | <domfarolino> | annevk: Yeah I don't know how I missed it lol |
| 18:56 | <domfarolino> | ta, sorry for the noise |
| 22:02 | <gsnedders> | PiersW: realise you may well not see this till next week, but if you want to talk about web-platform-tests at any point feel free to reach out |
| 22:06 | <PiersW> | gsnedders: I'm about (for a bit). Thanks - we run them under CI. They're very helpful in ensuring we've understood the specs. Currently a subset (pointless to run ones which we don't even attempt to implement), but that subset increases every month or so. |
| 22:17 | <gsnedders> | PiersW: are you using wptrunner or some custom runner? if the latter, how are you making sure you keep up-to-date on various changes? |
| 22:21 | <PiersW> | Custom runner, for historic reasons. Just update it occasionally. Not often enough. |
| 22:22 | <gsnedders> | PiersW: given we have a generic WebDriver (and a somewhat less maintained Selenium) runner in wptrunner, I'd hope it wouldn't be too hard to get it running under that FWIW. |
| 22:23 | <PiersW> | Bolted it on to our pre-existing test harness. In hindsight that might not've been too sensible (I wasn't involved because... because... it's written in blimmin' emacs lisp.) |
| 22:24 | <PiersW> | ah, we have selenium/web driver support. I didn't realise that. |
| 22:25 | <gsnedders> | PiersW: am happy to talk more about this at some point, probably when both of us are more around |
| 22:26 | <gsnedders> | PiersW: hell, you can probably convince me to come up to Cambridge easily enough |
| 22:26 | <PiersW> | Sure. Oh, that could work. Where are you? London? |
| 22:27 | <PiersW> | We could come down, too, if that works. The guy who wrote our emacs wpt import script lives in London. |
| 22:28 | <gsnedders> | PiersW: both myself and jgraham who deal with most of the WPT infra stuff are in London |
| 22:28 | <gsnedders> | Personally, I'd be happy to have an excuse to go to Cambridge for a day :) |
| 22:29 | <gsnedders> | But, like, if that means people from London on your side especailly going into your office then it's probably less worthhwile |
| 22:30 | <PiersW> | Heh. Nah, he commutes up to here. But I'm sure he'd be happy not to. |
| 22:31 | <gsnedders> | I guess it partly depends on how many other people it makes sense to have involved in any discussion. |
| 22:33 | <PiersW> | Well, one person here wrote the selenium stuff, another did the wpt import integration, and the rest of us just test against them. I've never got involved in the infrastructure part, just testing against them. |
| 22:33 | <PiersW> | They're very, very, helpful for regression testing. Couldn't write a browser without 'em. |
| 22:36 | <gsnedders> | PiersW: also happy to talk more generally about contributing any tests you do write upstream :) |
| 22:38 | <gsnedders> | (obviously there's very much limits to how much I can do on time I get paid for general WPT work, but I do have time if you want to talk about paying me directly to do anything related) |
| 22:38 | <PiersW> | Yeah, we should... Our own test system is less structured so easier to create a test for (can do a simple render text dump comparison, screen bitmap comparison or console comparison). |
| 22:42 | <PiersW> | Do you know emacs lisp? :-) |
| 22:43 | <gsnedders> | I might be an emacs users, but not really. :) |
| 22:43 | <gsnedders> | s/users/user/ |