Closed Bug 666746 Opened 13 years ago Closed 2 years ago

Support content opening new windows in another process

Categories

(Core :: DOM: Core & HTML, defect, P5)

x86
Windows 7
defect

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: benjamin, Unassigned)

References

Details

We will most likely want to isolate common app tabs (gmail/facebook) from common browsing activities. There are two techniques implemented by chrome (and gmail) which we should implement, which allows sites to open a new window without forcing it into the same process:

http://www.google.com/chrome/intl/en/webmasters-faq.html#newtab

The easiest approach is to use a link to a different web site that targets a new window without passing on referrer information. Google Chrome recognizes this as a hint to keep the new page isolated from the original page, and it will load the new page in a separate process. For example:

<a href="http://differentsite.com" target="_blank" rel="noreferrer">Open in new tab and new process</a>

If you want the new tab to open in a new process while still passing on referrer information, you can use the following steps in JavaScript:

    Open the new tab with about:blank as its target.
    Set the newly opened tab's opener variable to null, so that it can't access the original page.
    Redirect from about:blank to a different web site than the original page.

For example:

var w = window.open();
    w.opener = null;
    w.document.location = "http://differentsite.com/index.html";

Technically the original website still has access to the new one through `w`, but they treat .opener=null as a clue to neuter the window.
> <a href="http://differentsite.com" target="_blank" rel="noreferrer">Open in new
> tab and new process</a>

Does this give the new window a null opener?  Is that expected?

> Technically the original website still has access to the new one through `w`,
> but they treat .opener=null as a clue to neuter the window.

So if you try to actually touch it it throws?  Or something else?

If it throws, then on the face of it this is buggy: if you load a same-origin site in w, you should be able to access it.  :(
Yes, noreferrer has a null opener, this is already in bug 530396.

If you load a same-origin site in w *after* you set w.opener = null? I don't know what chrome does in this case.
Priority: -- → P5
Component: DOM → DOM: Core & HTML

I think any mechanism like this has been superseded by Fission.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.