706274 - ability to mirror docshells

Status: RESOLVED WONTFIX

(Core :: DOM: Navigation, defect)

Description

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

This is one of the ideas Gavin & I discussed around making global app tabs (587873) a priority without being too hacky on the front end.

The idea being this: We have an app tab in window A and open window B. Window B should have the app tab. I can make that work with a lot of watching and then swapping docshells when the tab in window B is focused so it can be interacted with. My unfocused app tab just has a random url (currently about:apptabs because I needed something), so things like switch-to-tab (and so many others) which look at browser.currentURI are going to be wrong. Also, without watching for loads in the non-active tab, it would be programatically possible to tell the non-active tab to navigate to some page (while expecting it to act on the global app tab).

So ideally we would be able to have a mirrored docshell & whatever needed so that without having to change the surface, things "just work" underneath.

Comment 1

[Boris Zbarsky [:bzbarsky]]

So what you want is to have a single docshell associated with multiple tabs, basically?  That is, the browser binding will operate on some other docshell, not the one actually created for the <browser> (but then still swap docshells on tab switch)?

Comment 2

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

Yea I guess it could work like that, but I was envisioning it working without having to swap docshells - <browser>s would use this shared docshell, new tabs could be added to use the same docshell, tabs could be closed and so long as there was 1 tab still using it the docshell would hang around. I don't know how feasible that would be or what other challenges it would bring up, but that feels ideal to me.

Comment 3

[Boris Zbarsky [:bzbarsky]]

So the thing is that docshells are currently tied to a docshell tree which includes the chrome.  For example, window.close() in the last docshell in a window closes that window.  But maybe we don't want that for app tabs?

If we want to make the content-window-to-chrome-window one-to-many, we'll have to figure out all the ways they interact and probably change most of them....

Comment 4

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

(In reply to Boris Zbarsky (:bz) from comment #3)
> So the thing is that docshells are currently tied to a docshell tree which
> includes the chrome.  For example, window.close() in the last docshell in a
> window closes that window.  But maybe we don't want that for app tabs?

Maybe not. Is that something we could maybe forward up to chrome first like we did with the link target stuff?

> If we want to make the content-window-to-chrome-window one-to-many, we'll
> have to figure out all the ways they interact and probably change most of
> them....

Is this a crazy idea? You don't seem like you're vehemently against something like this. Is this going to end up with (more) delicate code that in a year we regret ever writing it? (Dolske told me stories of print preview & issues with multiple views). Docshell & the content-chrome-window relationship are a bunch of black boxes to me so I don't have a good grasp on risk here.

I think it would be good to get moving on this asap if possible, whichever route we go. I'm happy to talk more if you need more info. Like I said, I don't know much about all of this, so if this isn't something you or somebody else can jump on, I can start down the rabbit hole.

Comment 5

[Boris Zbarsky [:bzbarsky]]

> Is that something we could maybe forward up to chrome first like we did with the link
> target stuff?

I can't recall what we did with link targets, but we'd need to do something with all users of GetParent on docshells, with web progress listeners, with treeowners, and so forth.

> You don't seem like you're vehemently against something like this. 

Well, I'm not vehemently opposed to general rearchitecture of docshell, no.  It won't be a short-term project, though.

> Is this going to end up with (more) delicate code that in a year we regret ever
> writing it? 

If we try to do a quick-and-dirty approach, almost certainly.

Basically, the proposal is to change a bunch of docshell invariants.  It can be done, if we're careful, but it'll be a good bit of work and we need a good plan for what the new invariants will be and whatnot.

Comment 6

[Paul [pwd]]

What happened with this? It seems to be have completely stalled?