WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
184716
Set RemoteDOMWindow's initial opener
https://bugs.webkit.org/show_bug.cgi?id=184716
Summary
Set RemoteDOMWindow's initial opener
Chris Dumez
Reported
2018-04-17 16:56:48 PDT
Set RemoteDOMWindow's initial opener.
Attachments
WIP Patch
(12.36 KB, patch)
2018-04-17 16:57 PDT
,
Chris Dumez
no flags
Details
Formatted Diff
Diff
Patch
(27.31 KB, patch)
2018-04-18 13:17 PDT
,
Chris Dumez
no flags
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Chris Dumez
Comment 1
2018-04-17 16:57:33 PDT
Created
attachment 338160
[details]
WIP Patch
Sam Weinig
Comment 2
2018-04-17 19:34:14 PDT
As I mentioned to Chris elsewhere, I think I might consider having RemoteDOMWindow::opener() return a WindowProxyController (and perhaps rename it to WindowProxy or DOMWindowProxy) since a WindowProxyController is just the window proxy part of an AbstractFrame. I would further change everything (in the IDLs) that returns a DOMWindow to return a WindowProxy instead.
Chris Dumez
Comment 3
2018-04-17 19:56:28 PDT
(In reply to Sam Weinig from
comment #2
)
> As I mentioned to Chris elsewhere, I think I might consider having > RemoteDOMWindow::opener() return a WindowProxyController (and perhaps rename > it to WindowProxy or DOMWindowProxy) since a WindowProxyController is just > the window proxy part of an AbstractFrame. I would further change > everything (in the IDLs) that returns a DOMWindow to return a WindowProxy > instead.
I think I could return a WindowProxyController instead of an AbstractFrame in this patch, I like the idea and this is a small change. Updating all the IDLs to use WindowProxy is definitely the way to go, I agree but I think this is out of scope of this patch. I can take care of it in a follow-up.
Chris Dumez
Comment 4
2018-04-18 11:52:42 PDT
(In reply to Sam Weinig from
comment #2
)
> As I mentioned to Chris elsewhere, I think I might consider having > RemoteDOMWindow::opener() return a WindowProxyController (and perhaps rename > it to WindowProxy or DOMWindowProxy) since a WindowProxyController is just > the window proxy part of an AbstractFrame. I would further change > everything (in the IDLs) that returns a DOMWindow to return a WindowProxy > instead.
Note that forcing the implementation to return a WindowProxyController means we have to null check the frame. Previously, we'd just return a potentially null frame and toJS() would take care of the null check for us.
Chris Dumez
Comment 5
2018-04-18 13:17:24 PDT
Created
attachment 338251
[details]
Patch
Sam Weinig
Comment 6
2018-04-18 13:31:05 PDT
Comment on
attachment 338251
[details]
Patch Very nice.
WebKit Commit Bot
Comment 7
2018-04-18 15:27:25 PDT
Comment on
attachment 338251
[details]
Patch Clearing flags on attachment: 338251 Committed
r230789
: <
https://trac.webkit.org/changeset/230789
>
WebKit Commit Bot
Comment 8
2018-04-18 15:27:27 PDT
All reviewed patches have been landed. Closing bug.
Radar WebKit Bug Importer
Comment 9
2018-04-18 15:28:31 PDT
<
rdar://problem/39543247
>
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug