Closed Bug 558192 (window-divorce) Opened 10 years ago Closed 2 years ago
Global Window (and related interfaces) into inner/outer
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
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.
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
Depends on: 968804
Depends on: 1032340
Depends on: 1032344
Depends on: 1032415
Depends on: 1032423
Depends on: 1032427
Assignee: nobody → khuey
Depends on: 1182316
Depends on: 1216401
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.
Depends on: 1241763
Depends on: 1241764
Depends on: 1245182
Depends on: 1245185
Depends on: 1245306
Depends on: 1245950
Depends on: 1256761
(In reply to Kyle Huey [:khuey] (email@example.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
This was fixed 2 months ago :-)
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.