| 02:51 | <Domenic> | Definitely not. The simplest way to see this is to consider the iframe case. An iframe will contain a single browsing context for all time. That browsing context can transition between different agents, living in different agent clusters, if you navigate the iframe cross-site. |
| 09:52 | <keithamus> | https://github.com/whatwg/html/pulls/keithamus there's a handful of open editorial PRs for the enumerated attributes. It'd be great to get https://github.com/whatwg/html/pull/9947 reviewed and merged as I get the sense it'll cause merge conflicts down the line. |
| 10:32 | <Noam Rosenthal> | As an action item from the last WHATNOT, I created https://github.com/whatwg/html/issues/9941 (defining what navigation type to give a tab-restore) I convinced myself that a tab-restore is actually closer to restoring from history than to a reload, but would love feedback as convincing myself has proven insufficient in the past. |
| 11:18 | <annevk> | keithamus: I merged that one and another small one; can take another look after lunch |
| 11:18 | <annevk> | keithamus: thanks for all the cleanup! |
| 11:18 | <keithamus> | Amazing thank you! |
| 12:03 | <annevk> | keithamus: one thing that helps with reviews is to do fixup commits (which we squash when landing); bit different from how WebKit does things and not possible when you need to rebase, but that generally makes it easier to see if anything besides your review comments got addressed, etc. |
| 12:04 | <keithamus> | Oh right, will do, thanks for calling that out. |
| 12:04 | <keithamus> | In the case of my recent rebase it was only your review comment ;) |
| 14:30 | <annevk> | Ms2ger 🇩🇪: if you make it to Berlin don't forget to say hi |
| 14:30 | <Ms2ger 🇩🇪> | Going in the other direction, sorry :) |
| 14:30 | <Ms2ger 🇩🇪> | Deutsche Bahn permitting |
| 14:31 | <annevk> | Hah, good luck! |
| 14:31 | <Ms2ger 🇩🇪> | (My next train has already been cancelled and uncancelled) |
| 14:56 | <akaster> | Definitely not. The simplest way to see this is to consider the iframe case. An iframe will contain a single browsing context for all time. That browsing context can transition between different agents, living in different agent clusters, if you navigate the iframe cross-site. |
| 15:04 | <akaster> | Is there some mechanism in the spec that I missed that talks about when we're supposed to move a browsing context to a new agent? |
| 16:30 | <annevk> | akaster: I assume you've seen how a browsing context group holds an agent cluster map? |
| 16:31 | <annevk> | akaster: but basically if you trace the callers of "create an agent" you should be able to find it |
| 16:31 | <annevk> | akaster: (clicking on the definition reveals the callers) |
| 16:31 | <akaster> | Oh, that links back to "obtain a similar origin window agent" |
| 16:32 | <annevk> | akaster: right so an agent can be reused, but if you navigate a document to a new document of a different not-yet-seen origin, you need a new agent |
| 16:33 | <annevk> | akaster: and due to bfcache a single browsing context can end up being responsible for several cross-site documents (and thus agents) |
| 16:34 | <akaster> | Is it expected that when you create a new agent that execution of the current algorithm will jump into the context of that agent? Or rather, onto the execution context stack of that new agent |
| 16:36 | <annevk> | akaster: the new document/worker will have to execute in the new agent, but the spec algorithm might also do some other bookkeeping things not related to JS code |
| 16:36 | <akaster> | Or am I still not thinking about this right. The way that all these concepts relate to threads and processes is still quite confusing. |
| 16:36 | <annevk> | akaster: an agent cluster is a conceptual process |
| 16:37 | <annevk> | akaster: an agent is a conceptual thread |
| 16:38 | <annevk> | In practice user agents coalesce multiple "conceptuals" into a single "physical" to limit resource usage, but the specification allows for more parallelism |
| 16:38 | <akaster> | Gotcha... Just need to wrap my head around what things are supposed to happen "to the user agent" (aka some abstract state that someone handles (?)) vs what are useful to model as an actual C++ object in memory of a particular process, whether it be the renderer, UI, or other helper |
| 16:39 | <annevk> | akaster: I see, most browsers have a "browser" process that would allocate these "agent cluster" processes |
| 16:39 | <annevk> | akaster: and then depending on needs there might be a GPU, network, etc. process |
| 16:40 | <akaster> | Right, in Ladybird at the moment we have a more or less standard architecture, I think. We have a browser process, and we have a WebContent process for each Tab, and a set of Network, ImageDecoding processes etc that could easily be shared but aren't at the moment for the WebContent process to use |
| 16:41 | <akaster> | But the way that we handle navigation is still very ad hoc |
| 16:41 | <akaster> | So aligning what the spec expects us to do as far as agents and agent clusters vs the current "just change the URL we load lmao" approach is ... Not straightforward. |
| 16:43 | <akaster> | So it sounds like, WebContent (aka the renderer) is supposed to be our agent cluster process. And every time we navigate to a url that needs a new agent cluster, we "should" create a new process. And most browsers at the moment ask the main Browser process (UI?) to create one for them |
| 16:45 | <annevk> | akaster: yeah, sounds like you have the same state WebKit is in, which is a problem for Spectre. You need different processes for nested documents. That requires quite a number of changes. |
| 16:45 | <annevk> | akaster: and yeah having the UI/browser process take some responsibility for navigations is needed I think. |
| 16:48 | <akaster> | Okay, thanks! I think I'll need to draw a lot of diagrams to wrap my head around how all this is supposed to work. Especially for the set of IPC interactions we need to have, and which spec records need to be shared between the processes, or at least transferred around. When talking to Domenic about my worker prototypes it was clear that we weren't modelling EnvironmentSettingsObjects in the way the spec authors intended |
| 16:48 | <annevk> | akaster: https://docs.google.com/presentation/d/1hi4gH7pJPHsg_hnIj77XN_ce54HIaNUnBLenVwohFVo/edit#slide=id.g5641ecbac9_0_131 might help for the high-level idea. |
| 17:11 | <akaster> | Gotcha... Well, talking to Andreas it sounds like we're going to try making every *agent* its own process, until we hit a snag. So this is going to be exciting to organize |
| 17:22 | <annevk> | I think you mentioned that before and I still don't quite understand that idea. Doesn't that make shared memory a whole lot harder? |
| 17:22 | <annevk> | In any event, I'm sure you're right that it'll be exciting. 😊 |
| 17:23 | <akaster> | Probably, but Andreas seems to think we can work around it with interprocess shared memory. I suspect WPT will be able to tell us if we're right or not |
| 17:24 | <annevk> | If that also allows you to do cross-process atomics and such I suspect that's correct, but it might be slow. Good to have a browser that does something different though. |
| 17:25 | <akaster> | Where's the fun in reimplementing chromium's architecture 😛 |
| 17:25 | <annevk> | Well if you're allocating a process for each agent cluster you're already different. But fair. |
| 17:26 | <akaster> | Correct and "mitigated" seems more interesting than trying to get things performant on the first pass. |
| 17:26 | <akaster> | I suspect we'll find all the reasons why other user agents do things the way they do. But we might find that some of those reasons don't matter on modern hardware anymore |
| 17:27 | <annevk> | True that, I hope y'all discover many new things. |
| 20:07 | <Travis> | Hello |