Bug 207185

Summary: _WKDownload should expose the originating FrameInfo
Product: WebKit Reporter: Brady Eidson <beidson>
Component: WebKit Misc.Assignee: Brady Eidson <beidson>
Status: RESOLVED FIXED    
Severity: Normal CC: achristensen, cdumez, commit-queue, ggaren, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
none
Patch
none
Patch
none
Patch
none
Patch none

Brady Eidson
Reported 2020-02-03 22:25:33 PST
_WKDownload should expose the originating FrameInfo <rdar://problem/58022576>
Attachments
Patch (16.30 KB, patch)
2020-02-03 22:44 PST, Brady Eidson
no flags
Patch (21.24 KB, patch)
2020-02-04 16:15 PST, Brady Eidson
no flags
Patch (22.53 KB, patch)
2020-02-04 16:54 PST, Brady Eidson
no flags
Patch (22.16 KB, patch)
2020-02-05 12:46 PST, Brady Eidson
no flags
Patch (22.14 KB, patch)
2020-02-05 12:49 PST, Brady Eidson
no flags
Brady Eidson
Comment 1 2020-02-03 22:44:22 PST
Brady Eidson
Comment 2 2020-02-03 22:44:55 PST
API test to come, but just wanted EWS to check the build, existing API tests, etc.
Brady Eidson
Comment 3 2020-02-04 16:15:12 PST
Geoffrey Garen
Comment 4 2020-02-04 16:22:56 PST
Comment on attachment 389731 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=389731&action=review > Source/WebKit/UIProcess/API/Cocoa/_WKDownload.mm:91 > + if (frameInfo.page() == nullptr) > + frameInfo.setPage(_download->originatingPage()); Under what conditions will a FrameInfo lack a page, and why is it correct under those conditions to claim that its page was the page that originated the download? (Does the API test demonstrate this case?)
Brady Eidson
Comment 5 2020-02-04 16:37:32 PST
(In reply to Geoffrey Garen from comment #4) > Comment on attachment 389731 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=389731&action=review > > > Source/WebKit/UIProcess/API/Cocoa/_WKDownload.mm:91 > > + if (frameInfo.page() == nullptr) > > + frameInfo.setPage(_download->originatingPage()); > > Under what conditions will a FrameInfo lack a page, Most callers of DownloadProxy::create don't have a page available, so they are never created with a page, so the answer is "always" > Does the API test demonstrate this case? It does. That said, I'll just go rework the DownloadProxy c'tor some more.
Brady Eidson
Comment 6 2020-02-04 16:54:32 PST
Geoffrey Garen
Comment 7 2020-02-05 11:15:18 PST
Comment on attachment 389745 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=389745&action=review r=me > Source/WebKit/UIProcess/API/APIFrameInfo.h:57 > + void setPage(WebKit::WebPageProxy* page) { m_page = page; } You can remove this setter now. > Source/WebKit/UIProcess/API/Cocoa/_WKDownload.h:45 > +@property (nonatomic, readonly) WKFrameInfo *originatingFrameInfo WK_API_AVAILABLE(macos(WK_MAC_TBA), ios(WK_IOS_TBA)); Let's call this "originatingFrame". Even though the data type is WKFrameInfo, I think "frame" reads better, and it appears to be more consistent with our other WKFrameInfo APIs.
Brady Eidson
Comment 8 2020-02-05 12:46:24 PST
Brady Eidson
Comment 9 2020-02-05 12:49:43 PST
Alex Christensen
Comment 10 2020-02-05 13:05:47 PST
Note You need to log in before you can comment on or make changes to this bug.