WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
207185
_WKDownload should expose the originating FrameInfo
https://bugs.webkit.org/show_bug.cgi?id=207185
Summary
_WKDownload should expose the originating FrameInfo
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
Details
Formatted Diff
Diff
Patch
(21.24 KB, patch)
2020-02-04 16:15 PST
,
Brady Eidson
no flags
Details
Formatted Diff
Diff
Patch
(22.53 KB, patch)
2020-02-04 16:54 PST
,
Brady Eidson
no flags
Details
Formatted Diff
Diff
Patch
(22.16 KB, patch)
2020-02-05 12:46 PST
,
Brady Eidson
no flags
Details
Formatted Diff
Diff
Patch
(22.14 KB, patch)
2020-02-05 12:49 PST
,
Brady Eidson
no flags
Details
Formatted Diff
Diff
Show Obsolete
(4)
View All
Add attachment
proposed patch, testcase, etc.
Brady Eidson
Comment 1
2020-02-03 22:44:22 PST
Created
attachment 389633
[details]
Patch
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
Created
attachment 389731
[details]
Patch
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
Created
attachment 389745
[details]
Patch
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
Created
attachment 389849
[details]
Patch
Brady Eidson
Comment 9
2020-02-05 12:49:43 PST
Created
attachment 389851
[details]
Patch
Alex Christensen
Comment 10
2020-02-05 13:05:47 PST
http://trac.webkit.org/r255845
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