#502: HTML Horizontal Review: Windows, navigation, agents and agent clusters

Visit on Github.

Opened Apr 13, 2020

This is a subtask of #499. Please review these three HTML PRs:

Discussions

Discussed Apr 27, 2020 (See Github)

Tess: there are uncontroversial changes ... David & I to schedule 121?

[decide to do it here]

HTML issue 4617

Tess: this change to HTML - ties together browsing contexts and associated agent cluster. [gives 50k foot overview of agent clusters - agents are thread - clusters are process boundary]. In HTML there is a browsing context - a browsing context group are contexts able to reach each other - e.g. access to each others globals. Therefore they have to be in the same agent cluster. This change tries to tie together the ecmascript notion of agent clusters with html notion of browsing contexts. You can also have dedicated workers. A browsing context group and an agent cluster are roughly 1:1 but an agent and a browsing context are not 1:1.

... If you look at the actual diff.. what's interesting ... this adds the text that says every browsing context group has an associated agent cluster map. If you consider a browser tab with some iframes and popup windows.. relationship between these things becomes fuzzy. the process boundary tends to be at a site rather than an origin. A big chunk got removed - a hand-wavey description of how these things related and they've added in something that's much more detailed. This is a better description of how browsers work today that ties html concepts more closely to ecmascript concepts.

Dan: are there still areas where things fall through the cracks?

Tess: the followup work has covered all these cases - as of today. One of the things that this changes - it adds several algorithms that tie things together. Every agent cluster has one agent in it that corresponds to a ... window. A window has an agent but a window can also spin off things... but each agent cluster has only one agent that is a window. this change has the algo that specifies that...

... good example of a change to html that is difficult to do but not controversial.

David: how much is this a thing that .. given that there is variance in implementation .. how much room does it leave?

Tess: leaves as much as ecmascript leaves... there is leeway to have different process of models. It just clarifies the wiggle room. The idea is we

Comment by @hober Apr 27, 2020 (See Github)

I went ahead and checked off whatwg/html#4410 and whatwg/html#4851. They're both slight tweaks that bring the spec into alignment with implementations.

Comment by @hober Apr 27, 2020 (See Github)

We reviewed whatwg/html#4617 on today's call. We're happy to see the relationships between various ECMAScript and HTML concepts be tightened up. @dbaron wondered if this change reduced the number of degrees of freedom implementations have in choosing process models, but is confident that this received sufficient review at the time. Closing.

Comment by @annevk Apr 27, 2020 (See Github)

https://tc39.es/ecma262/#sec-forward-progress is the fundamental constraint. This affects dedicated workers and shared workers as specified (they have [[CanBlock]] set to true, though in implementations this might only be true for dedicated workers at the moment). Everything else can in theory run on the same thread, though on CPU architectures impacted by Spectre this would be ill-advised. Hope that helps.