Bug 184716

Summary: Set RemoteDOMWindow's initial opener
Product: WebKit Reporter: Chris Dumez <cdumez>
Component: BindingsAssignee: Chris Dumez <cdumez>
Status: RESOLVED FIXED    
Severity: Normal CC: cdumez, commit-queue, esprehn+autocc, ews-watchlist, ggaren, kondapallykalyan, rniwa, sam, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on: 184515    
Bug Blocks: 184466, 184756    
Attachments:
Description Flags
WIP Patch
none
Patch none

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
DetailsFormatted DiffDiff
Patch (27.31 KB, patch)
2018-04-18 13:17 PDT, Chris Dumez 		no flags
DetailsFormatted DiffDiff
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.