| 06:23 | <domfarolino> | annevk: Need to sanity check something. Imagine the following code `image = new Image(); image.src = "https://example.com"; image.referrerPolicy = "no-referrer"`. This should send a request with no referrer header right? |
| 06:25 | <domfarolino> | Currently Firefox does not apply a Referer header, while Chrome has a full Referer. I believe Chrome is broken here? |
| 06:26 | <domfarolino> | I think the flow is like this, per spec: 1) Src is set, and #updating-the-image-data is invoked, queueing a microtask to finish the algo and fetch the image 2) Image's referrer policy is updated 3) The microtask is eventually run, referencing the latest `referrerPolicy` value of the image, fetching the resource |
| 06:31 | <domfarolino> | (eh, pretend my example is not missing a semicolon) |
| 06:33 | <annevk> | domfarolino: yeah seems like a bug in Chrome |
| 06:51 | <domfarolino> | annevk: So I think by that logic, the following would send a full referrer: `image = new Image(); image.src = "https://example.com";; queueMicrotask(() => { image.referrerPolicy = "no-referrer" })` |
| 07:24 | <annevk> | domfarolino: yeah, if the spec matches reality |
| 07:25 | <annevk> | The image spec hasn’t been maintained well unfortunately |
| 07:25 | <domfarolino> | Yeah :( |
| 07:27 | <domfarolino> | The above is correct in Chrome, but only because the first example fails (aka Chrome sends Referer more than it should) |
| 07:27 | <domfarolino> | But fails in Firefox (use Promise.resolve().then() instead of queueMicrotask) |
| 07:28 | <domfarolino> | oddly enoguh, even if you use setTimeout in Firefox (instead of Promise.resolve().then()) it still fails. |
| 07:28 | <domfarolino> | as in, the referrer is not sent when I think it should be. But oh well |
| 07:32 | <annevk> | domfarolino: does Fx support queueMicrotask? Also when does Fx include it? |
| 07:35 | <annevk> | domfarolino: oh, you're using Promise.resolve() because of lack of queueMicrotask support? |
| 07:36 | <domfarolino> | Yes |
| 07:36 | <domfarolino> | to your second question |
| 07:36 | <annevk> | domfarolino: it still failing with setTimeout is rather peculiar then, I guess that means it queues a task instead |
| 07:36 | <annevk> | domfarolino: and timers have higher priority |
| 07:36 | <domfarolino> | yeah I guess it must |
| 07:37 | <domfarolino> | ahh |
| 07:37 | <annevk> | domfarolino: if you queue a timeout from a timeout, does that change it? Or versus postMessage()? |
| 07:37 | <annevk> | domfarolino: to be fair, queue a task for "await a stable state" as I mentioned in the PR would make more sense and is required for when you invoke that from "in parallel" |
| 07:40 | <domfarolino> | annevk: queueing a timeout from a timeout does not change it at least, request is still sent w/o a Referer. |
| 07:41 | <domfarolino> | annevk: Hmm, queue a task just to queue microtask, and finally continue in parallel? |
| 07:42 | <annevk> | domfarolino: it cannot be random which task a microtask ends up in |
| 07:42 | <annevk> | domfarolino: that's bad |
| 07:43 | <domfarolino> | annevk: True. At the same time, queueing a task I don't think is safe from a compat perspective, right I think it breaks existing behavior (my latest comment in response to yours in the PR thread) |
| 07:44 | <annevk> | domfarolino: haven't read that yet, but it seems from these results it's rather unclear what the processing model is |
| 07:45 | annevk | goes to the PR |
| 07:46 | <domfarolino> | annevk: My assumption is that the only issue with #updating-the-image-data is that it calls "await a stable state", when it should instead be manually queueing a microtask. |
| 07:46 | <domfarolino> | That assumption (and the corresponding spec change) would not change current behavior, it is just sort of semantic |
| 07:47 | <annevk> | domfarolino: it would mean that the algorithm can only ever be invoked from the main thread, which does seem like a good thing to enforce really |
| 07:47 | <domfarolino> | But assuming the intention is to have #updating-the-image-data to queue a microtask to continue the rest of the algorithm (which is basically what it currently does, just by using "await a ..." incorrectly), I do not think we can change that to a task w/o compat fallout |
| 07:47 | <annevk> | domfarolino: maybe we should note that for the ambiguous caller case that it would have to queue a task if it wasn't same thread |
| 07:48 | <annevk> | domfarolino: fair, but it seems that browsers don't queue a microtask? At least Firefox does something else |
| 07:49 | <domfarolino> | annevk: But do we have to cater to ambiguous caller cases, if there are none in the spec? (Aka, no invocations of #updating-the-... actually happen from an in-parallel context) |
| 07:50 | <domfarolino> | annevk: Ok true, browsers are obviously not doing this correctly, hence my two examples above :( |
| 07:51 | <annevk> | domfarolino: doesn't the spec have an ambiguous caller case? |
| 07:52 | <annevk> | "A user agent that obtains images on demand must update the image data of an img element whenever it needs the image data" |
| 07:52 | <annevk> | That's extremely vague |
| 07:52 | <domfarolino> | annevk: lol true I suppose, that's pretty bogus |
| 08:08 | <domfarolino> | annevk: Also, if we were to "wait" for some viewport condition to happen before we create the #concept-request, we're defer the URL parsing relative to the node (...) as late as possible. Are you not OK with that? |
| 08:08 | <domfarolino> | (same with the state of some of the attributes, i.e., crossOrigin, referrerPolicy) |
| 08:10 | <annevk> | domfarolino: yeah, URL parsing has side effects |
| 08:10 | <annevk> | domfarolino: this would be bad for blob URLs for instance |
| 08:11 | <domfarolino> | annevk: sorry, really don't know much about blob URLs. Could you elaborate? |
| 08:12 | <annevk> | domfarolino: the moment you parse a blob URL the returned URL record takes ownership of the underlying Blob object (so if the blob URL were to be revoked, fetching that URL record later would not fail) |
| 08:12 | <annevk> | domfarolino: (implementations have bugs here) |
| 08:16 | <domfarolino> | annevk: Ah, so if we defer parsing, the blob URL could be revoked before parsing, and therefore fetching would fail in that case? |
| 08:16 | <annevk> | domfarolino: yeah |
| 13:26 | <dtapuska> | annevk: On https://github.com/whatwg/html/pull/4617 I wanted to define window agent not pulling in "similar-origin" because I want to be able to define some feature policy that forces separate agent allocations |
| 13:27 | <dtapuska> | So I tried to not have the "similar-origin" name in it.. And I wondered if all the references in the spec should be to the window agent, and however that is allocated is up to the similar-origin window agent algorithm |
| 13:29 | <dtapuska> | In terms of the "has an associated agent" that was my definition of a strong reference. Perhaps I'm not understanding how you mean a strong reference. |
| 13:32 | <annevk> | dtapuska: I don't think we need two types of window agents and I'd rather not rename the one we have for this refactoring |
| 13:33 | <annevk> | dtapuska: furthermore, an Agent Cluster holds a set of Agents, giving one of those Agents a special pointer seems inappropriate even if the window one is somewhat special |
| 13:33 | <annevk> | dtapuska: given how often we need to retrieve it simply retrieving the window type from the set seems fine |
| 13:34 | <dtapuska> | Huh which Agent has a special pointer? |
| 13:34 | <annevk> | dtapuska: your agent cluster has a special pointer to the window agent |
| 13:35 | <dtapuska> | Yes it has a pointer to the "one" window agent |
| 13:35 | <annevk> | dtapuska: and it's also somewhat wrong as there are quite a few agent clusters that don't |
| 13:35 | <dtapuska> | The rest of agents in the agent cluster are all unique |
| 13:35 | <dtapuska> | So how do you get the window agent of the window cluster for the algorithm to return it? |
| 13:36 | <annevk> | I'd write it the way I wrote it in the original issue I think |
| 13:36 | <annevk> | At least, I remember it saying something like "Return the similar-origin window agent of the agent cluster" |
| 13:36 | <annevk> | Which seems accurate enough until TC39 has created more precise language |
| 13:37 | <dtapuska> | Ok so generally leaving it a little undefined |
| 13:38 | <dtapuska> | I think that is fine.. because my feature policy thing was going to early out in obtaining an agent cluster |
| 13:38 | <annevk> | dtapuska: well, there's ever one agent of that type so it's not quite undefined I'd say |
| 13:38 | <annevk> | only ever* |
| 13:39 | <annevk> | And yeah, any kind of isolation would be at the agent cluster level |
| 13:39 | <dtapuska> | What about the definition of "similar-origin window agent" what do you think that would be like? |
| 13:40 | <annevk> | dtapuska: I guess I haven't quite thought through yet whether an Agent Cluster holding strong references makes sense, but I guess it does given how termination is supposed to work |
| 13:41 | <annevk> | dtapuska: I think ideally it doesn't hold realms and instead whenever we create a realm we add a pointer to the agent, as per the TC39 discussion |
| 13:42 | <annevk> | dtapuska: if we don't do that we'd need to start out with the empty set of realms and add the realms as they are created (and remove them at unclear times?) |
| 13:42 | <dtapuska> | Right.. so it is just an Agent that can block is false. That really is it |
| 13:43 | <annevk> | Yeah, I don't think we have an opinion on the other fields |
| 13:44 | <annevk> | (Well, and we enforce the set of realms to be Window objects with certain origins, but that's not really tied to creation.) |
| 13:45 | <dtapuska> | Can we write some non-normative text around it, maybe a note indicating that the Realms that use this agent should all have the same origin and should be allocated via the obtain-similar-origin-window-agent algorithm? |
| 13:45 | <dtapuska> | s/same/similar |
| 13:46 | <annevk> | dtapuska: as a statement of fact without "should" that'd be fine |
| 13:46 | <annevk> | dtapuska: it's enforced elsewhere (primarily agent cluster selection I guess) |
| 13:47 | <dtapuska> | Ok; so I'll use "will" instead |
| 13:49 | <annevk> | dtapuska: "all have ... and are allocated via ..." would also work and is slightly nicer |
| 14:10 | <dtapuska> | annevk: One other thing related to "shared agent clusters".. I named it this way because when I allocate agent clusters based on a feature policy they won't end up in the "agent cluster map". |
| 14:10 | <dtapuska> | The agent cluster map seemed to indicate with the name that it would have all agent clusters |
| 14:10 | <dtapuska> | but perhaps that is just me |
| 14:14 | <annevk> | dtapuska: so where do you store them instead? |
| 14:15 | <annevk> | dtapuska: the key abstraction was meant to allow for storing all things there so they're also easy to find during teardown |
| 14:16 | <dtapuska> | They aren't stored for those documents that have the policy, they can't share data with anyone else.. so the strong reference from the global to the agent is the main thing that is holding onto the agent |
| 14:16 | <annevk> | dtapuska: at least all things that have similar-origin window agents |
| 14:19 | <annevk> | dtapuska: we might still have to let them go through the browsing context group though in some way so when they are created they get the appropriate COOP/COEP state |
| 14:20 | <annevk> | dtapuska: but maybe it's correct that nothing but the document needs to keep a reference (we'll have to be careful about defining the lookup for dedicated worker agent creation) |
| 14:20 | <Domenic> | I'm not as deep into this as you two but it seems to me in an ideal world there should be a single "reference root", probably the UA, which then keeps things alive. With a general ownership structure of UA -> agent cluster -> agent -> realm <-> global. Not sure where BC groups/BCs fit in there though. |
| 14:21 | <Domenic> | To be clear though I think having a perfect reference graph is pretty far down on the list of important things to formalize |
| 14:21 | <annevk> | domfarolino: BCG holds "window" agent clusters; UA holds shared/service worker agent clusters and BCGs |
| 14:21 | <annevk> | Domenic: ^^ |
| 14:22 | <annevk> | Domenic: although there was a suggestion that a UA holds session history which holds TLBCs which are part of a BCG, which might be better once we get to session history |
| 14:23 | <annevk> | And yeah, it's not entirely clear to me how in dtapuska's model we'd tear down the agent cluster easily when the tab is closed, it seems we'd have to go hunt for it |
| 14:24 | <annevk> | So I do think it's somewhat important to think this through, with the exception of session history although we should keep that in the back of our minds as well |
| 14:24 | <dtapuska> | So can we have a list of all agent clusters, and a separate map of shared agent clusters? |
| 14:26 | <dtapuska> | I don't think we need that immediately in this PR, but leads to the "shared agent cluster" naming over "agent cluster map" |
| 14:27 | <annevk> | dtapuska: what did you think about my earlier idea? That we only have a map and the document with a feature policy ends up with a special agent cluster key |
| 14:32 | <dtapuska> | annevk: Ya I thought about that too. But the question is what keying material you'd use that would be consistent for the document. You'd need to allocate some type of 'opaque origin' for agent cluster lookup that then the document could maintain I guess |
| 14:33 | <annevk> | dtapuska: key can be anything, so UUID or opaque origin or whatever would be fine |
| 14:33 | <annevk> | dtapuska: we could even use the Document object |
| 14:34 | <dtapuska> | No you can't use the Document object... the Agent is allocated *before* the document is created |
| 14:34 | <annevk> | dtapuska: oops, yeah, we'd have to generate a unique identifier |
| 14:35 | <dtapuska> | But ya a "agent cluster origin" could be defined as origin and if policy is set it becomes a opaque origin, and that is passed to the obtain similar-origin window agent algorithm. |
| 14:36 | <annevk> | To be clear, "agent cluster key is an origin or a scheme-and-site" is meant to be extensible if we have a need, it doesn't have to fit into this mold necessarily |
| 14:37 | <annevk> | But opaque origin as key even though the agent does not have an opaque origin would certainly work, but we might wanna carefully explain what's going on there if we go down that route |
| 14:37 | <dtapuska> | Yup ok.. I don't disagree.. so I can change it back to "agent cluster map" then |
| 18:59 | <annevk> | dtapuska: maybe there should be some kind of lookup on a TLBC that falls back to a BCG so you can more eagerly collect when a TLBC is closed, but not observable so maybe not worth it, although maybe it is until we have remote WindowProxy; yeah it is observable that way… |
| 21:16 | <lgrahl> | o/ There was a cool web API overview page with links to all the specs but I forgot the URL. Maybe someone of you knows what I mean? |
| 21:17 | <lgrahl> | Found it: https://platform.html5.org/ |