569000 - Would the real outer window please stand up?

Status: RESOLVED DUPLICATE of bug 580128

(Core :: XPConnect, defect)

Description

[Jason Orendorff [:jorendorff]]

For compartmentalization (bug 563106) we need inner and outer windows to be in different compartments. Therefore they must no longer share a prototype.

It is unclear how this works right now, but it's clearly a straight-up blocker. More to follow.

Comment 1

[Jason Orendorff [:jorendorff]]

More generally I need a plan for the outer window, the location object, and their associated prototypes and methods. Since they can change principals, it's unclear where to put them.

Andreas and mrbkap have a plan to magically swap the global object for a wrapper. I'm not sure how I feel about regular brain transplants, but it could work.

Comment 2

[Jason Orendorff [:jorendorff]]

I came up with another plan, where the outer window and location object live in a separate compartment which I'm calling Outland. The problem is that it'll be slow when you use a window object directly (because of the wrappers involved). mrbkap proposed making the window object just be special. That might be the best course.

The brain transplant thing is a little nontrivial with compartments. After each brain transplant you would need to rewrap all direct references and reconstruct the whole JSScope since sprops are per-compartment too (for lots of reasons).

Comment 3

[Jason Orendorff [:jorendorff]]

Andreas has mostly convinced me brain transplants are better than Outland. The last paragraph of comment 2 is no problem: when we navigate, all properties on the outer window get wiped out.

The problem with the Outland scheme is that it's complicated and retains the wrapper around the outer window, which is slow.


=== The brain transplant plan ===

There is an "outer window JSObject" per outer window, per compartment. So for example, if a given tab has visted sites a.com, b.org, and c.edu, then we have outer window JSObjects in compartments A, B, and C.

Say we're currently looking at a.com. Then the outer window JSObject in compartment A is the real XPCWN. The other two are XOWs of that.

Now suppose we navigate to b.org. We update *all* the outer window JSObjects.

  - A's outer window object was the real XPCWN. It becomes a XOW of B's.

  - B's outer window object was a XOW of A's. It becomes the real XPCWN.

  - C's outer window object was a XOW of A's. It becomes a XOW of B's.

  - Chrome might have an XPCNW and/or a SJOW of A's outer window object.
    Those wrappers needs to be updated too (they become wrappers of B's
    outer window) in order to avoid double-wrapping.

To do this update, each outer window will need a list of all compartments that have a reference to it. (This isn't just the list of everything in the history; there's also window.open to consider. So: all references, really.)

This sounds like a lot of work. I'll need help. We should keep thinking about other ways to do it.

Comment 4

[Jason Orendorff [:jorendorff]]

The scheme outlined above eliminates the XOW around the outer window (when it's same-origin).

But without further work, `window.x` will still fall off trace anyway, because it calls the getter on the outer window, which ultimately does a JS_GetProperty on the inner window. That's the global object. We'll deep-bail.

Comment 5

[Jason Orendorff [:jorendorff]]

Brain transplants are still the best idea we have. I think Andreas wants to take this one.

At the same time mrbkap is pushing the outer window object away from being overly similar to the inner window (see bug 574517, bug 574974, bug 558192).

Comment 6

[Jason Orendorff [:jorendorff]]

Resolving forward since bug 580128 has a patch.