Would the real outer window please stand up?

RESOLVED DUPLICATE of bug 580128

Status

()

Core
XPConnect
RESOLVED DUPLICATE of bug 580128
8 years ago
8 years ago

People

(Reporter: jorendorff, Assigned: gal)

Tracking

Other Branch
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

8 years ago
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.

Updated

8 years ago
Assignee: general → nobody
Component: JavaScript Engine → XPConnect
QA Contact: general → xpconnect
(Reporter)

Comment 1

8 years ago
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.
(Reporter)

Comment 2

8 years ago
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).
(Reporter)

Comment 3

8 years ago
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.
Summary: Separate inner and outer window prototype chains → Would the real outer window please stand up?
(Reporter)

Comment 4

8 years ago
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.
(Reporter)

Comment 5

8 years ago
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).
(Assignee)

Updated

8 years ago
Assignee: nobody → gal
(Assignee)

Updated

8 years ago
Blocks: 584198
(Reporter)

Comment 6

8 years ago
Resolving forward since bug 580128 has a patch.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 580128
You need to log in before you can comment on or make changes to this bug.