Closed Bug 558192 (window-divorce) Opened 10 years ago Closed 2 years ago

Split nsGlobalWindow (and related interfaces) into inner/outer

Categories

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

defect
Not set

Tracking

()

RESOLVED FIXED

People

(Reporter: jorendorff, Assigned: Nika)

References

Details

They're really not terribly similar, so having them be the same class doesn't make much sense.

It leads to a ton of code that tests IsInnerWindow() to see if we need to forward or not. We'll still need the forwarding code, but we can avoid the if-statement.
Assignee: general → nobody
Component: JavaScript Engine → DOM
QA Contact: general → general
who's going to take this?
I was hoping to get to this this quarter.
Andreas had discussed (IIRC with mrbkap) using harmony:proxies here. Possible?

/be
Seems better to me to do that in a followup step.  This is more aimed at using a different C++ class than at using a different JS class.  One thing at a time...
We use proxies in JS now. We need to split the C++ classes so things are less implicitly unsafe for C++ users.
Alias: WindowProxy
Assignee: nobody → mrbkap
Summary: Make the outer window a different class from the inner window (HTML5 WindowProxy) → Split nsGlobalWindow (and related interfaces) into inner/outer
Version: Other Branch → Trunk
Assignee: mrbkap → nobody
Depends on: 1192774
The plan here is roughly:

1. Move all methods off of nsIDOMWindow (bug 1216401)
2. Make it possible to specify in XPIDL whether a parameter is an inner or outer window.
3. Make an nsPIDOMWindowInner/Outer, and make every place in the code base use one or the other.
4. Move methods specific to inner/outer to the appropriate nsPIDOMWindowInner/Outer.
5. Split nsGlobalWindow.
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #6)
> The plan here is roughly:
> 
> 1. Move all methods off of nsIDOMWindow (bug 1216401)
> 2. Make it possible to specify in XPIDL whether a parameter is an inner or
> outer window.
> 3. Make an nsPIDOMWindowInner/Outer, and make every place in the code base
> use one or the other.
> 4. Move methods specific to inner/outer to the appropriate
> nsPIDOMWindowInner/Outer.
> 5. Split nsGlobalWindow.

Steps 1-3 have already happened.  Instead of continuing with steps 4 and 5, I have a new plan.

JS security is now handled entirely by the JS engine and the wrapper system.  We never create a wrapper for the outer window or expose it to JS.  So instead of splitting nsGlobalWindow, we should instead move all of the methods/variables from the outer window to the docshell.  Then we can kill the concept of inner and outer windows entirely, and nsGlobalWindow will be just the inner window.  WindowProxy will exist solely as a JS abstraction, and where C++ needs to manipulate windows across navigations it will hold onto and use the docshell.
Assignee: khuey → nobody
I'm going to be trying to push this through in Q4, so assigning this to myself.
Assignee: nobody → michael
Depends on: 1400984
Depends on: 1401379
Depends on: 1405372
Depends on: 1405805
Depends on: 1414974
Depends on: 1415645
Depends on: 1416384
Depends on: 1419144
Depends on: 1419597
This was fixed 2 months ago :-)
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.