| 13:18 | <dtapuska> | annevk: How is the origin on a document generally assigned? I see it only as through document construction, in https://html.spec.whatwg.org/multipage/browsers.html#creating-browsing-contexts. I'm trying to match the spec to Chromium's code. When we create a document we already know the origin and I was trying to enforce that. I think the problem stems from the fact that Chromium doesn't follow.. |
| 13:18 | <dtapuska> | https://html.spec.whatwg.org/multipage/browsing-the-web.html#read-html and a new document object is created with the origin when a page is loaded so we go into that. So how is the origin set correctly when using https://html.spec.whatwg.org/multipage/browsing-the-web.html#read-html ? |
| 13:20 | <annevk> | dtapuska: the whole document creation process is defined very poorly |
| 13:21 | <annevk> | dtapuska: origin is therefore defined with action-at-a-distance: https://html.spec.whatwg.org/#origin:document-2 |
| 13:23 | <dtapuska> | annevk: We can't define it in that fashion for agent.. because an agent shouldn't change as the page loads... ie; the agent needs to be fixed at document creation.. So fundamentally we need to adjust the navigation algorithms to force a load of the document with the origin predetermined. |
| 13:23 | <dtapuska> | My process was... determine the origin of the document, create the agent associated, create the execution context, create the document |
| 13:24 | <dtapuska> | determining the origin of the document requires us to determine the sandbox flags first.. as well, but I think that makes it clear how you want feature policy sandbox flags to work |
| 13:24 | <annevk> | dtapuska: a document's origin shouldn't change either, but yes, agreed |
| 13:25 | <dtapuska> | I do need to remove that other section about determining if two windows are the same agent.. basically it should be if the realm's execution content's agent is the same then they are the same.. |
| 13:25 | <annevk> | (I'm also not trying to hold this up as an example of good design; my goal is that eventually we have "create a document" that takes various parameters) |
| 13:26 | <annevk> | (I guess I'm trying to say, please don't take inspiration from this setup) |
| 13:26 | <dtapuska> | I agree.. I think my latest patch is far better than the last attempt.. Are you really confused by it? I thought it was clearer. |
| 13:28 | <annevk> | dtapuska: I am, as I don't quite see how it works when you navigate an existing browsing context |
| 13:28 | <annevk> | dtapuska: at that point you might end up in a different agent cluster, but how that works if determining an origin only really works for popups is not very clear to me |
| 13:31 | <annevk> | dtapuska: one other nit, you should make "obtain a" part of the <dfn> in various places |
| 13:32 | <dtapuska> | Yes so that is certainly broken. Do we have a response in these pieces of code: https://html.spec.whatwg.org/multipage/browsing-the-web.html#read-html |
| 13:32 | <dtapuska> | Because "create a Document" really should be passing in the origin. |
| 13:33 | <annevk> | It's called from code that has a response and can do the right thing |
| 13:33 | <annevk> | Untangling it however is another matter |
| 13:35 | <dtapuska> | ie; can we change https://html.spec.whatwg.org/multipage/browsers.html#creating-a-new-browsing-context to also take an optional resource origin? And change those spots to pass a resource origin? |
| 13:35 | <annevk> | It's on my list of things to do, but email/GitHub/admin/review ends up taking so much time I never really get to it |
| 13:35 | <annevk> | dtapuska: creating a browsing context isn't really the complicated piece |
| 13:36 | <annevk> | dtapuska: that already has an origin (opaque) or its creator origin (whatever its value) |
| 13:36 | <annevk> | dtapuska: that covers about:blank |
| 13:36 | <annevk> | dtapuska: then there's navigation |
| 13:36 | <annevk> | dtapuska: that keeps the browsing context around, but changes what is displayed |
| 13:37 | <annevk> | dtapuska: that's where things get hairy |
| 13:38 | <annevk> | (and it might also not be that complicated since in the abstract it's not, but the way the spec is written just ...) |
| 13:51 | <dtapuska> | I guess I'm confused why: "the user agent must queue a task to create a Document object, mark it as being an HTML document, set its content type to "text/html", initialize the Document object".. Could we define new steps for "initialize a browsing context with a new document" ? ie; the separate "create a Document" and "initialize the document object" create this issue that the origin is not defined on document creation. |
| 13:51 | <dtapuska> | or that it transitions from oqaque origin -> actual origin |
| 13:51 | <dtapuska> | which creates issues for defining the agent cluster |
| 13:53 | <annevk> | That, and the fact that we create the document before we create the global it's created in |
| 13:55 | <annevk> | dtapuska: so the actual change to the browsing context happens later |
| 13:55 | <annevk> | dtapuska: there's two callers of "set the active document" |
| 13:56 | <annevk> | dtapuska: one is during browsing context creation and the other is in history traversal, which is what navigate bottoms out to |
| 14:19 | <dtapuska> | Ok; so perhaps "initialize a browsing context with a new document" is a poor name, it could be simply "create a document and execution context" algorithm... does that approach make sense? |
| 14:34 | <annevk> | dtapuska: ah yeah, I see what you mean, something like that would make sense |