516747 - Electrolysis: link targeting across content/chrome

Status: RESOLVED FIXED

(Core :: DOM: Navigation, defect)

Description

[Benjamin Smedberg]

Link targeting needs to be handled correctly across content/chrome: new windows may need to be redirected into tabs by the chrome process; named targets may need to be resolved to existing windows by the chrome process (and that navigation may cause the window to be rendered by a different content process).

Comment 1

[Boris Zbarsky [:bzbarsky]]

OK, so general thoughts:

1)  If link targeting happens via window.open, the resulting window is returned
    to the caller so must be in the same process, no?
2)  If link targeting happens via target="" then the resulting window gets its
    .opener set to the caller; again must be in the same process.

So it seems to me that we can guarantee that link/window.open targeting need only examine windows in the same process.  Agreed?  If not, then what are we doing about .opener and the return value of window.open?

Comment 2

[Benjamin Smedberg]

Yes, in general. In fact for the Fennec case we only need to have one content process overall. What does need to work is that new windows need to go through the parent process in such a way that Fennec can open new tabs, and Firefox can open popup windows/tabs for them. Allowing nsIBrowserDOMWindow to work, I think?

From the chromium docs: "There is one exception: Chromium allows pages to fork a new rendering process via JavaScript, in a way that is compatible with the links that appear in Gmail messages. A page can open a new tab to about:blank, set the new tab's window.opener  variable to null, and then redirect the new tab to a cross-site URL. In that case, a renderer-initiated navigation will cause Chromium to switch renderer processes in the new tab. Thus, opening a link from Gmail (or pages with similar logic) will not adversely affect the Gmail process."

Comment 3

[Boris Zbarsky [:bzbarsky]]

Attachment: Add a method to fennec's nsIBrowserDOMWindow implementation to add a tab and return its browser

Comment 4

[Boris Zbarsky [:bzbarsky]]

Attachment: Hack fennec's tab-opening code to not throw

Comment 5

[Boris Zbarsky [:bzbarsky]]

Attachment: Implement nsIInterfaceRequestor on TabChild, so the nsDocShellTreeOwner can get things off it

Comment 6

[Boris Zbarsky [:bzbarsky]]

Attachment: Add a new API to nsIBrowserDOMWindow to like openURI but returning a frame loader owner

I'm not totally convinced of this API.  In particular, my use case doesn't need aURI or aOwner.  It does need the other two, sort of; what I'm passing now isn't quite right.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Attachment: Make it work

I can't visually inspect it, since fennec's barfing on tab switches, for example, but I checked in a debugger that ProvideWindow returns a window succesfully.

Comment 8

[Benjamin Smedberg]

I have no good opinions about the XXX comments in these patches, by the way: I suspect that we should make a more invasive change to nsIBrowserDOMWindow so that there aren't two APIs, so make sure followup bugs are filed if necessary.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Filed bug 537428 on sorting out the right nsIBrowserDOMWindow API, as well as some icky details regarding modal content windows and the like.

Filed bug 537429 on the TabChild GetInterface question.

Pushed:
http://hg.mozilla.org/mozilla-central/rev/5d75d1ef28c1
http://hg.mozilla.org/mozilla-central/rev/15b58ed34cb0
http://hg.mozilla.org/mozilla-central/rev/1e25778852f2