| 06:20 | <annevk> | zcorpan: I think I said as much in that issue? |
| 06:25 | <Yoav Weiss> | I agree it was a mistake. I also think that preconnect requiring a definition ahead of time of whether the resources eventually fetched on it would be CORS-enabled or not is bad. (this may be a Chromium-only requirement, not sure) |
| 06:27 | <Yoav Weiss> | I think Firefox got it right at the time, but Chromium net code wasn't amenable to align with that. |
| 08:17 | <annevk> | I don't even understand how the crossorigin was made to apply to same-origin fetches. Was there a brief period where fonts were not fetched with credentials ever or some such? |
| 08:17 | <annevk> | But even then that would be a change to the semantics of the crossorigin attribute that I don't think were ever documented. |
| 08:20 | <annevk> | Yoav Weiss: that's for cross-origin fetches. Those are somewhat more tricky. I forgot what Gecko did exactly there and how sound that was. I suspect all of this might still be broken in various ways. |
| 08:22 | <Yoav Weiss> | For cross-origin fetches, I agree that we should use different connections for CORS and no-CORS resources. But Chromium uses different pools even for same-origin fetches, because of something related to how the redirects work that I don't quite remember now |
| 08:24 | <Yoav Weiss> | So cors anonymous same-origin fetches do happen with credentials, but over a different connection than a no-cors same-origin fetch |
| 08:27 | <annevk> | I don't think you need to use different connections for CORS and no-CORS? Connections are keyed on credentials, not CORS. |
| 08:31 | <zcorpan> | annevk: I don't see anyone in the issue agreeing with Yoav Weiss 's proposal in OP to make as=font imply crossorigin=anonymous |
| 08:32 | <Yoav Weiss> | annevk: I 100% agree. Chromium net folks at the time disagreed due to reasons that may no longer be applicable. I may try to take a stab at rectifying the situation (but that's orthogonal to Simon's suggestion) |
| 08:34 | <Yoav Weiss> | (nm, misread) |
| 08:40 | <annevk> | Ah okay. So I guess the issue is that by default preload sets credentials mode to include? And so for fonts that will do the wrong thing as by default they use credentials mode same-origin. |
| 08:40 | <annevk> | I mean, this also impacts module JavaScript in the same way, no? But perhaps nobody uses that. |
| 08:41 | <Noam Rosenthal> | it would impact modules in the same way, but as=script is also for classic scripts |
| 08:41 | <annevk> | Right, so maybe preload is just kinda broken. |
| 08:42 | <Noam Rosenthal> | that's a bit of a general statement, no? |
| 08:42 | <annevk> | It includes "kinda", which should offset that. |
| 08:43 | <Noam Rosenthal> | that's why "a bit" of a general statement |
| 08:43 | <zcorpan> | For fetches that are mode=cors by default, the ergonomics of preload is not great |
| 08:43 | <zcorpan> | I think making as set the defaults to match the later request is an improvement |
| 08:43 | <annevk> | (mode=cors and credentials mode=same-origin (which admittedly is all of them unless you fiddle with things)) |
| 08:44 | <annevk> | I'm not sure, that only helps with font and thereby masks the issue from developers for even longer. |
| 08:45 | <annevk> | In five years you'll get "why does it work for fonts but not module scripts?" |
| 08:45 | <zcorpan> | as=module ? |
| 08:45 | <zcorpan> | or modulescript |
| 08:45 | <annevk> | Maybe, but try to specify that. It goes against the as attribute pretty hard. |
| 08:46 | <zcorpan> | as=script type=module |
| 08:46 | <Noam Rosenthal> | type is already a mime-type |
| 08:46 | <Noam Rosenthal> | I think as=modulescript would not be that difficult to specify TBH |
| 08:47 | <Noam Rosenthal> | we already translate fetch to ``, we can translate modulescript to be script + default cors |
| 08:47 | <annevk> | Allowing type=module could maybe still work? I like that better than as=modulescript given how that mismatches with destination and such. |
| 08:47 | <annevk> | Aside: what's Sec-Fetch-Dest for fetch()? |
| 08:48 | <Noam Rosenthal> | Isn't it something like "empty"? checking... |
| 08:48 | <annevk> | Yeah it is. Ugh. |
| 08:51 | <Noam Rosenthal> | pecified here: https://w3c.github.io/webappsec-fetch-metadata/#abstract-opdef-set-dest |
| 08:54 | <annevk> | I guess I don't mind as impacting these other settings as long as we have a holistic plan for all of them. And the plan should probably involve some MDN updates. |
| 09:02 | <Yoav Weiss> | modules have modulepreload which is defined as a different link rel |
| 09:03 | <Yoav Weiss> | I think that having as=font imply crossorigin anonymous makes sense, and can be done now in a backward compatible way (as folks that don't include it are simply holding it wrong, and have unused preloads) |
| 09:04 | <Yoav Weiss> | We could do the same for modulepreload if it doesn't already (I'm not sure, as I wasn't involved) |
| 09:05 | <zcorpan> | Oh right, it is a different rel. So module scripts are already good I think |
| 09:05 | <annevk> | Yoav Weiss: modulepreload is for an entire module graph, but maybe that should always be used? Hmm. |
| 09:06 | <Yoav Weiss> | I don't believe the "entire module graph" bit is actually implemented in Chromium (but could be wrong) |
| 09:07 | <annevk> | Is there preloading for media text tracks? |
| 09:07 | <Yoav Weiss> | I also can't imagine a case where I'd want to preload a single module without its dependencies |
| 09:10 | <Yoav Weiss> | Looks like "track" is supported: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/loader/preload_helper.cc;l=343 |
| 09:12 | <annevk> | I think there's some disagreements on text tracks with respect to CORS as well. |
| 09:14 | <zcorpan> | https://wpt.fyi/results/html/semantics/embedded-content/media-elements/track/track-element/cors?label=experimental&label=master&aligned |
| 09:18 | <Noam Rosenthal> | I agree with Yoav Weiss here. Changing fonts to crossorigin=anonymous by default has no downsides, and we can do the same for track if these fun disagreements are resolved |
| 09:19 | <Noam Rosenthal> | (forgot about modulepreload, it indeed diminishes the reasoning to handling it in preload) |
| 09:21 | <annevk> | zcorpan: are we sure those tests are good? Having 2/3 engines fail most of the tests seems like a very bad state to be in. |
| 09:23 | <zcorpan> | annevk: I wrote them when foolip (iirc) implemented track support in Presto. I would need to check if they still match the spec. |
| 09:26 | <zcorpan> | But yeah, agreed it seems bad. Tracks are not really taintable, so if webkit and chromium do no-cors fetches and allow cross-origin tracks, it seems like a SOP violation |
| 09:30 | <zcorpan> | http://wpt.live/html/semantics/embedded-content/media-elements/track/track-element/cors/009.html passes in chromium but fails in webkit |
| 09:37 | <zcorpan> | annevk: I think 009.html matches what the spec says at least |
| 09:38 | <zcorpan> | https://html.spec.whatwg.org/#create-a-potential-cors-request sets mode = "same-origin" |
| 11:51 | <foolip> | annevk: I wrote them when foolip (iirc) implemented track support in Presto. I would need to check if they still match the spec. |
| 15:34 | <annevk> | Wait any MathML element can be a link? https://github.com/WICG/sanitizer-api/issues/168#issuecomment-2021383832 They all match :link then? |
| 15:36 | <annevk> | Hmm, seems to work in Gecko, but not WebKit. It's clickable in WebKit though. https://software.hixie.ch/utilities/js/live-dom-viewer/saved/12504 |
| 15:37 | <annevk> | This seems extremely silly and Chromium clearly has the correct model here, but who knows what would break. |
| 23:00 | <zcorpan> | annevk: ugh... |
| 23:02 | <zcorpan> | Folks can use HTML <a href> in mathml |
| 23:03 | <zcorpan> | bkardell: do websites use mathml links? |
| 23:29 | <zcorpan> | https://github.com/w3c/mathml-core/issues/142 |