| 08:45 | <sideshowbarker> | https://stackoverflow.com/questions/74624587/how-to-get-resource-timing-api-entry-without-including-resource-scheduling-time (for anybody here who’s familiar with the Resource Timing API and might be able to answer) |
| 09:07 | <annevk> | Domenic: I filed https://github.com/whatwg/html/issues/8563 on the window.name thing after conforming it's indeed on navigable now |
| 09:08 | <annevk> | johannhof: you might wanna find a W3C channel for that question; WHATWG doesn't use ReSpec |
| 09:10 | <annevk> | Noam Rosenthal: how would opt-out work? Are only 2xx responses ever cached? |
| 09:11 | <annevk> | Noam Rosenthal: anyway, thanks, that helps! Adding a note somewhere to explain the purpose of the purpose header would be nice I think, once we decide how to specify it. |
| 09:12 | <annevk> | salty-horse: it's an opportunity! HTML was abandoned too at some point and that led to the WHATWG. 😊 |
| 10:46 | <Domenic> | I forgot we also have disowned??? This really seems like too much state... How much would break if we just collapsed this into "opener browsing context"... |
| 11:08 | <annevk> | Domenic: I recall when I last looked at this with Nika we found that Gecko at least had all these bits |
| 11:08 | <annevk> | Domenic: as in, I think there are code paths that grab the opener even when JS can no longer access it |
| 11:09 | <annevk> | Domenic: solving 313 and seeing what changes we can make might be a way out, but getting anyone to invest in that issue is like pulling teeth :-( |
| 11:58 | <Domenic> | You should give it a go? I'll support! |
| 12:02 | <johannhof> | johannhof: you might wanna find a W3C channel for that question; WHATWG doesn't use ReSpec |
| 13:00 | <Noam Rosenthal> | Noam Rosenthal: anyway, thanks, that helps! Adding a note somewhere to explain the purpose of the purpose header would be nice I think, once we decide how to specify it. Cache-Control: no-store when they get that header. |
| 13:00 | <Noam Rosenthal> | thanks! |
| 13:26 | <annevk> | Noam Rosenthal: hmm, will that bypass all memory caches appropriately? |
| 13:27 | <Noam Rosenthal> | annevk: prefetch doesn't touch the memory cache |
| 13:27 | <Noam Rosenthal> | it's just a nudge to the HTTP cache |
| 13:27 | <Noam Rosenthal> | so if you set a no-store, the next fetch would get it from the network again |
| 13:27 | <Noam Rosenthal> | it's totally how it works today |
| 13:28 | <Noam Rosenthal> | ... memory caches are resource-type-specific and prefetch has no resource-type |
| 13:29 | <Noam Rosenthal> | annevk: added a Fetch-Metadata issue for setting the header, https://github.com/w3c/webappsec-fetch-metadata/issues/84. The description there lists the use cases for the header |
| 13:29 | <annevk> | Noam Rosenthal: well, but a naïve service worker would cache it, no? |
| 13:29 | <Noam Rosenthal> | annevk: sure. I don't think that's a problem |
| 13:30 | <Noam Rosenthal> | if the service wants to opt-out of HTTP caching and the service worker overrides it, the service-worker gets precedence |
| 13:30 | <Noam Rosenthal> | would also recommend to send a 204 so that a very naive SW would not cache it |
| 13:31 | <annevk> | I think 204 might still be cached? You'd want a 400 or something. |
| 13:31 | <annevk> | (That's why I was asking above about status.) |
| 13:32 | <Noam Rosenthal> | service workers can still cache 4xx/5xx if they want to |
| 13:36 | <annevk> |
|
| 13:37 | <annevk> | I guess with put() they still can if they really wanted to. Hmm. |
| 13:43 | <Noam Rosenthal> | annevk: I'm not opposed to adding another error condition for put() where if the request's initiator is prefetch and the status is 204 |
| 13:44 | <Noam Rosenthal> | ... but ok, I think it's ok if the documentation for now suggests a 503 status code |
| 13:45 | <annevk> | I dunno if that's needed, but definitely want to be cautious with documentation around this |
| 13:46 | <Noam Rosenthal> | sure thing. I think that once everyone aligns on the details we'll write something to help avoid footguns with this |
| 14:49 | <annevk> | smaug: thoughts on https://github.com/whatwg/html/issues/8544#issuecomment-1326103455? |
| 14:51 | <smaug> | annevk: any shadow tree? |
| 14:52 | <smaug> | ah, I guess one needs to have access to those anyhow |
| 14:53 | <annevk> | smaug: yeah so in this case the script has access to elementInternals and some same-document shadow trees |
| 14:53 | <annevk> | smaug: I guess the question is how likely is it that there's some other script that also has access to elementInternals but not those other same-document shadow trees |
| 14:53 | <annevk> | smaug: given elementInternals.shadowRoot it's pretty clear we can at the very least expose that one |
| 14:55 | <smaug> | I've always considered elementInternals as a thing which is , well, internal. If you give it to outside world, you've lost the encapsulation, or you've given rights to access the internals by the parties which you trust. |
| 14:57 | <annevk> | smaug: and "trust" in that case includes shadow tree references they may or may not have then? That was my thinking too |
| 16:27 | <nika> | Domenic: I recall when I last looked at this with Nika we found that Gecko at least had all these bits |
| 16:29 | <annevk> | nika: oh hey! So potentially the opener field got be "none", "disowned", actual reference? |
| 16:30 | <nika> | I think it's independent, as you can also set up an opener for an existing BC by navigating it with named targeting |
| 16:31 | <nika> | so {opener: BrowsingContext?, hadOriginalOpener: bool} |
| 16:31 | <nika> | (as you could have an opener, but e.g. be a frame which was name-targeted) |
| 16:32 | <annevk> | So we have: auxiliary bc, opener, disowned |
| 16:32 | <annevk> | I think only auxiliary would have hadOriginalOpener set to true |
| 16:33 | <annevk> | But I think there was also a reason we couldn't just set opener to null, but maybe that was wrong |
| 16:33 | <annevk> | Would require some blame digging |
| 16:35 | <Noam Rosenthal> | annevk: with prefetch and CORS-preflight, I'm trying to understand what you meant in https://github.com/whatwg/html/pull/8111#issuecomment-1329169381 |
| 16:36 | <annevk> | Noam Rosenthal: we probably want to set it the same way we set the Fetch Metadata headers; but I haven't checked what implementations do today |
| 16:40 | <annevk> | I wonder if there's some problem with how window.opener is defined. It seems that once you set it it'll be disowned forever, seemingly across origins. That can't be right. |
| 16:48 | <annevk> | nika: so I think the question is mainly whether name targeting uses opener as a way to determine whether the name targeting should succeed or result in a new browsing context https://github.com/whatwg/html/issues/5569 (if the data structure is as you say it is I guess the answer is no) |
| 16:50 | <nika> | I wonder if there's some problem with how |
| 16:51 | <nika> | nika: so I think the question is mainly whether name targeting uses opener as a way to determine whether the name targeting should succeed or result in a new browsing context https://github.com/whatwg/html/issues/5569 (if the data structure is as you say it is I guess the answer is no) |
| 16:51 | <annevk> | nika: it clears it, but it currently cannot be set again to something else |
| 16:52 | <nika> | oh, interesting, I don't think we do that |
| 16:52 | <annevk> | nika: although maybe it can, I guess it writes a new property and those would perhaps not be on the WindowProxy? Hmm |
| 16:53 | <nika> | I'm not familiar enough with the spec, for us when you set the opener a second time by doing named targeting, it'll set the "real" opener - i.e. it'll persist across navigations |
| 16:54 | <annevk> | nika: right, there's named targeting setting but there's also setting the JS setter to "x" |
| 16:54 | <annevk> | Named targeting indeed directly goes to the internal field, but the JS setter does something else |
| 16:55 | <nika> | Oh yeah, it does |
| 16:55 | <annevk> | And it does seem that in the current spec if you do window.opener = null followed by a named target set window.opener would return null which is prolly wrong. |
| 16:55 | <nika> | https://searchfox.org/mozilla-central/rev/c1180ea13e73eb985a49b15c0d90e977a1aa919c/dom/base/nsGlobalWindowInner.cpp#3414-3431 |
| 16:56 | <nika> | We set the opener to null if you are trying to set it to null, and otherwise we redefine the property |
| 16:56 | <nika> | And that won't persist across navigations |
| 16:56 | <annevk> | Okay, sounds like we should remove disowned. And leave "hadOpener" to auxiliary (which is top-level only, but only top-level can have one from the onset afaik) |
| 16:58 | <nika> | (I could potentially be missing something, but that's my memory - We also track things like the "One true sandbox navigator", but I think that's an independent mechanism) |
| 17:02 | <annevk> | Code seems to support it. |
| 21:55 | <sideshowbarker> | https://stackoverflow.com/questions/74634392/fetch-raw-gzip-encoded-web-page-into-uint8array |