| 00:02 | <domfarolino> | Personally I’d be fine with just new Image() doing so, but would like to know Jake’s thoughts as he’s had the most feedback in that realm. Good call |
| 13:38 | <dtapuska> | annevk: where in the spec is the opaque origin assigned based on the sandbox flags? |
| 13:49 | <annevk> | dtapuska: it's bad speccing, but "If the Document's active sandboxing flag set has its sandboxed origin browsing context flag set" |
| 13:50 | <annevk> | Once we get to the point where we know when to allocate a Document given a bunch of state, we should be doing this origin assignment there |
| 13:54 | <dtapuska> | annevk: because the determination of the agent cluster needs to be after that point.. |
| 13:55 | <dtapuska> | That is why I have it in those steps after the application of the sandbox |
| 13:55 | <annevk> | dtapuska: well, the current setup is wrong |
| 13:56 | <Domenic> | annevk: ping for https://github.com/whatwg/html/pull/4473 green checkmark and/or opinions on multiplication operator typography |
| 13:57 | <annevk> | dtapuska: we should not be able to allocate a document without an agent and we should be able to determine an origin for an upcoming agent/global/document without creating a document first |
| 13:57 | <dtapuska> | annevk: I agree, and I like your approach, but the question is how do we really get there. Chrome has a DocumentInit that we pass into the Document constructor, it really seems we need to specify that... and that the agent would be assigned in the construction of the DocumentInit.. |
| 13:57 | <dtapuska> | as well as the opaque origin |
| 13:58 | <annevk> | Domenic: I guess I wonder if there is any style guide that other graphic specs use, but I'm prolly about to be disappointed |
| 14:00 | <annevk> | dtapuska: yeah, I discussed this other thing with Ian Clelland that I'm also running into now that we have this bunch of inherited state (CSP list, referrer policy, feature policy, base URL) that we really ought to copy when navigation begins (from whoever initiated) and then use when we create the document to default things that are not overridden |
| 14:00 | <annevk> | explicitly in case it's a document created by about:blank, srcdoc, blob:, data:, etc. |
| 14:00 | <annevk> | dtapuska: which is vaguely related, but different |
| 14:01 | <annevk> | Domenic: I'll r+ given fserb said okay and it's an improvement |
| 14:01 | <Domenic> | \o/ |
| 15:51 | <annevk> | dtapuska: Domenic: perhaps allocating the agents at the wrong point in time is an improvement indeed over waiting for proper documents, I'll have to think about that suggestion some more |
| 15:52 | <annevk> | dtapuska: Domenic: I hadn't really considered it so far since it doesn't help Cross-Origin-Opener-Policy, which requires replacing the browsing context |
| 16:14 | <Domenic> | Ah yeah, that makes sense. To me it's all just a long backlog, and the more incremental progress we can make the better. |
| 16:27 | <cybai> | Domenic: I have a question about `fetch a module script graph` |
| 16:28 | <cybai> | I found the step 23 in https://html.spec.whatwg.org/multipage/#prepare-a-script said "Let settings object be the element's node document's relevant settings object." and pass it to `fetch a module script graph` in step 24.6 for both classic and module scripts |
| 16:29 | <cybai> | However, in step 2 of https://html.spec.whatwg.org/multipage/#fetch-a-module-script-tree, we pass two `setting object` to `internal module script graph fetching procedure` |
| 16:30 | <annevk> | dtapuska: one thing that struck me is that it does not remove the same-site agent stuff, it seems it should be possible to remove that as agents are now explicitly allocated/selected, but admittedly I did not study in detail yet |
| 16:30 | <cybai> | We can know from the description of `internal module script graph fetching procedure`, the first setting object is `fetch client settings object` and the second one is `module map settings object` |
| 16:30 | <cybai> | Should we pass two different setting object from "prepare a script" step 24.6 instead? |
| 16:30 | <cybai> | Thanks 🙇 |
| 16:33 | <cybai> | (will it be good to file an issue for this?) |
| 16:36 | <dtapuska> | annevk: ya I didn't know if we wanted to store the agent somewhere and that would make it easier.. I "Obtain" an agent but I don't stash it somewhere.. A same-agent window can just be defined as if the agent is the same object... |
| 16:40 | <annevk> | dtapuska: aah I see, I think we need to stash it as the same-site thing is broken when the browsing context is discarded or some such |
| 16:41 | <annevk> | dtapuska: though basically if you put it in the agent cluster you can always get it from there as it’ll be the only agent for that key |
| 16:41 | <annevk> | dtapuska: only window agent |
| 16:44 | <dtapuska> | annevk: My idea is that there may be agent clusters not in the shared agent cluster table though |
| 16:44 | <dtapuska> | annevk: consider a policy as I proposed, a "document-access" policy basically puts a document in its own agent |
| 16:44 | <dtapuska> | so it doesn't need to go into the table. |
| 16:45 | <annevk> | dtapuska: those should not matter here as the lookup path is diff? |
| 16:45 | <dtapuska> | Nor does the table contain the correct agent cluster.. if I look it up based on domain it might return something else |
| 16:46 | <dtapuska> | Why would the lookup path be diff.. it isn't an opaque origin |
| 16:46 | <annevk> | I was assuming that if there is a policy we would alter the key or look elsewhere |
| 16:47 | <annevk> | Otherwise you end up with the same cluster |
| 16:49 | <dtapuska> | Right I was thinking the policy could be implement as "if policy set, return a new AgentCluster{ new Agent()}" instead of looking at the table.. ie; basically a step inserted into "obtain similar-origin window agent" |
| 16:50 | <dtapuska> | that was why I called it "shared agent clusters" as opposed to "list of all agent clusters" |
| 16:50 | <Domenic> | cybai|leave: for those cases, they are the same. The worker cases are where they are different. |
| 16:51 | <Domenic> | cybai|leave: it's fine to file issues for questions like that, or ask here :). |
| 16:53 | <annevk> | dtapuska: sure, but when there’s no policy getting the agent from the bcg’s agent clusters seems fine |
| 16:56 | <dtapuska> | annevk: Yes it would be, but if we implemented a policy then it would be problematic, we'd need to stash it somewhere. Also a lookup might be expensive if we consider adding a rule around IsPlatformObjectSameOrigin to check that they are same-agent windows. |
| 16:59 | <annevk> | dtapuska: I suspect I can leave more considered design feedback tomorrow, but I don’t really see why that is yet. Getting to an agent from a global should be really cheap and does not require a lookup |
| 16:59 | <dtapuska> | annevk: Sounds good.. have a good evening |
| 17:00 | <annevk> | dtapuska: I was missing that as well, allocating globals in the agents rather than out-of-band |