| 03:29 | <MikeSmith> | about rel=preload in Link headers, in Chrome is there a way to opt out of it? some user option/flag? |
| 03:29 | <MikeSmith> | see https://stackoverflow.com/questions/60064866/for-fetch-request-from-chrome-extension-how-to-prevent-chrome-from-also-automat |
| 04:43 | <annevk> | That seems like a bug, except perhaps if the site uses push, but why would that show up as requests? Surely the console knows |
| 05:29 | <yhirano> | annevk: I'm happy to answer any questions for https://github.com/mikewest/corpp/pull/8. |
| 05:39 | <MikeSmith> | annevk: The OP doesn’t cite any console error messages. In my experience with reading a lot of StackOverflow questions, it seems like a lot of devs don’t actually think to look at the console errors. Which suprises me (or used to...) |
| 05:53 | <MikeSmith> | annevk: btw that site is using HTTP/2 so maybe it is actually also using push. Do you know of a way I can tell if it is using push? |
| 05:53 | <MikeSmith> | the site is https://victoryroadvgc.com/ |
| 05:54 | <MikeSmith> | if I look at the requests in the Network pane, I see some where the Initiator is listed as "Other"... maybe that indicates they’re coming from push? |
| 05:56 | <MikeSmith> | s/in the Network pane/in the Network pane in Chrome/ |
| 07:51 | <annevk> | MikeSmith: there are CDNs that translate preload into push so that is certainly plausible |
| 07:52 | <annevk> | MikeSmith: no experience debugging personally |
| 07:53 | <annevk> | yhirano: will look more closely today I hope |
| 08:01 | <annevk> | yhirano: I think the problem with that approach is that it’s not future proof; at least, I think you want enforce value A, while getting a report for value B |
| 08:02 | <annevk> | (Thanks for the extremely clear written summary!) |
| 08:05 | <annevk> | yhirano: if we’ll never expect to extend this header it seems fine, but other Googlers have suggested new values |
| 08:09 | <yhirano> | annevk: we can introduce a new parameter, say report-as, when necessary. |
| 08:09 | <yhirano> | annevk: at this moment report-as is fixed to "require-corp" so we don't need it |
| 08:20 | <annevk> | yhirano: true, but it still limits us in ways; e.g., we couldn't add an optional parameter to require-corp |
| 08:20 | <annevk> | yhirano: but maybe that's okay |
| 08:38 | <yhirano> | annevk: thanks. Would that be a problem for COOP? |
| 08:41 | <yhirano> | annevk: we want to have a consistent syntax for COEP reporting and COOP reporting if possible |
| 08:41 | <annevk> | yhirano: it's hard to say in advance |
| 08:42 | <annevk> | yhirano: if we're okay sticking with enums it's not a problem |
| 08:43 | <annevk> | yhirano: https://github.com/w3c/webappsec-feature-policy/issues/362 is somewhat related |
| 08:49 | <annevk> | yhirano: I added a comment there to express my overarching concern; last time some of us discussed this in person nobody had a really compelling take for one solution over another |
| 08:51 | <annevk> | I'm probably overthinking it though as most headers don't grow that many values |
| 08:55 | <yhirano> | annevk: yeah. I still think the simplest one is good for the current COOP&COEP proposal, and it will not be too bad to make the reporting syntax complex when they grow... |
| 14:46 | <gsnedders> | given an HTMLImageElement `img`, does img.src = "/example.png"; img.src = "/example.jpg"; cause one (1) network request? (given step 8 of the update the image data?) |
| 14:52 | <annevk> | gsnedders: should be 1 |
| 14:53 | <gsnedders> | okay, far as I can see we have no tests for this |
| 14:54 | <gsnedders> | (don't worry, I'm only writing tests along these lines which get progressively more evil, who knows what interop is like) |
| 14:55 | <annevk> | gsnedders: because that would be lovely |
| 14:55 | <annevk> | gsnedders: someone contracted you to work on the img element? |
| 14:55 | <annevk> | (not sure why the first message didn't get send directly) |
| 14:56 | <gsnedders> | annevk: no, just playing around with some kinda crazy ideas in my head and I feel like I should check browsers actually do the right underlying behaviour before I start relying on it |
| 14:56 | <gsnedders> | so don't expect anything super-exhaustive, just the cases I care about for what I'm playing with :) |
| 14:56 | <annevk> | Fair enough |
| 14:57 | <annevk> | Alternative plan: get super popular so browsers have to align around what you happen to do |
| 15:19 | <domfarolino> | gsnedders: We don't have tests for a lot of the "relevant mutations" and intricacies in the #updating-the-image-data microtask-queueing logic, and there seems to be a decent interop gap. I talked with zcorpan about this a little recently, it would be great to get a lot of tests for this stuff written! I'm happy to help |
| 16:59 | <annevk> | Domenic: do you recall why Worker.fromString(...) is not yet a thing? Writing a Blob wrapper is rather tedious |
| 17:04 | <TabAtkins> | Similarly, we should have a way to load up a worklet from a string rather than a url; someone filed an issue about that a few days ago. |
| 17:07 | <annevk> | Yeah, the current setup is rather awkward. Having said, I'm sure this has been discussed before |
| 17:07 | <annevk> | that* |
| 17:18 | <annevk> | domfarolino: I'll look once more tomorrow, but I think your change was fine |
| 17:18 | <annevk> | domfarolino: from your checklist we're still awaiting a test though right? |
| 17:19 | <annevk> | domfarolino: and I guess it'd be nice if ecobos (or hiikezoe) had a final skim |
| 22:35 | <domfarolino> | annevk: yep hiikezoe’s test should be it if you’re ok with the spec |
| 22:35 | <domfarolino> | Sure I’m happy waiting for a final skim |