Introduce an abstraction between pipeline and constellation?

[asajeffrey]

At the moment, we have two levels of abstraction:

• Pipeline is per-browsing context
• Constellation is global

we do not have a level of abstraction between these, that is per-top-level-browsing-context. This causes issues in the context of browser.html, where there is more than one tlbc, e.g. #11220.

cc @Ms2ger @ConnorGBrewster @paulrouget

[jdm]

There is only one top-level browsing context in browser.html, which is the root page that contains the iframes for the tabs. Let us not confuse the issue further by claiming otherwise :)

[asajeffrey]

@jdm: oh, do we have a naming issue here? The history API talks about top-level browsing contexts, and in the case of browser.html there'll be one those per tab, yes?

[asajeffrey]

IRC conversation: http://logs.glob.uno/?c=mozilla%23servo&s=23+May+2016&e=23+May+2016#c436814

[jdm]

@asajeffrey A top-level browsing context has a strict definition. If we want to treat the browsing contexts that represent tabs in browser.html in a special manner, we should use a different name for them.

[asajeffrey]

@jdm yes, but from the point of view of a tab running inside browser.html, shouldn't the tab be the top-level browsing context, not browser.html itself?

[cbrewster]

@jdm since each tab is a mozbrowser iframe shouldn't each frame appear as a top-level browsing context https://developer.mozilla.org/en-US/docs/Web/API/Using_the_Browser_API

[paulrouget]

In a mozbrowser iframe, window == top.window.

[Ms2ger]

There's two other concepts we have to take into account: the unit of related browsing contexts and the unit of related similar-origin browsing contexts. I think the latter would correspond to a ScriptThread.

[asajeffrey]

Oh, and there's auxiliary browsing contexts too. What fun! At the moment, I don't think Servo has these, since it doesn't have tabs or windows.

Can we treat mozbrowser iframes as auxiliary browsing contexts? They are very similar, in that they create new top-level browsing contexts. This would give us one less thing to think about :) @paulrouget?

[paulrouget]

Can we treat mozbrowser iframes as auxiliary browsing contexts?

Looks about right. What about window.opener in this case?
What was the initial use case that a auxiliary browsing contexts was supposed to cover?

[asajeffrey]

Auxiliary browsing contexts were for things like tabs and maybe pop-ups I think. Window.opener is a tricky one... It should be the tab that did the navigation, not browser.html. Not sure how to handle the case where b.html does the navigation, e.g. opening a bookmark.

[asajeffrey]

Urgh, I realized a tricky case... @paulrouget, when a mozbrowser iframe completes loading, does it send a load event to its opener? Or should it send just a mozbrowserloadend event?

[asajeffrey]

#11430 is a first step towards this, making the constellation aware of which frames are mozbrowser iframes.

[paulrouget]

does it send a load event to its opener? Or should it send just a mozbrowserloadend event?

I don't know how Gecko/Gaia works, but in browserhtml, we only rely on the mozbrowserloadend event.

[asajeffrey]

OK, that's good, we can treat a mozbrowser iframe as an auxiliary browsing context for most things, I think it's just the moz* events that are special.

[asajeffrey]

It looks like we can get away with just making the constellation and script threads aware of which frames are top-level browsing contexts, so we don't need a separate abstraction layer.