WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
168981
Make WKMenuItemIdentifiersPrivate.h private header
https://bugs.webkit.org/show_bug.cgi?id=168981
Summary
Make WKMenuItemIdentifiersPrivate.h private header
Aakash Jain
Reported
2017-02-28 12:08:12 PST
WebKit2/UIProcess/API/Cocoa/WKMenuItemIdentifiersPrivate.h is a project header, it contains various NSStrings which are exported in the binary. This header should be private so that symbols from headers matches with binary exactly.
Attachments
Proposed patch
(2.39 KB, patch)
2017-02-28 12:09 PST
,
Aakash Jain
no flags
Details
Formatted Diff
Diff
Updated patch
(5.29 KB, patch)
2017-02-28 12:29 PST
,
Aakash Jain
ap
: review-
Details
Formatted Diff
Diff
Previous patch again
(2.39 KB, patch)
2017-03-02 12:34 PST
,
Aakash Jain
no flags
Details
Formatted Diff
Diff
Updated patch
(3.55 KB, patch)
2017-03-03 18:25 PST
,
Aakash Jain
thorton
: review-
buildbot
: commit-queue-
Details
Formatted Diff
Diff
Archive of layout-test-results from ews117 for mac-elcapitan
(1.76 MB, application/zip)
2017-03-03 21:39 PST
,
Build Bot
no flags
Details
Updated patch
(3.61 KB, patch)
2017-03-06 13:46 PST
,
Aakash Jain
no flags
Details
Formatted Diff
Diff
Archive of layout-test-results from ews101 for mac-elcapitan
(1.16 MB, application/zip)
2017-03-06 14:35 PST
,
Build Bot
no flags
Details
Show Obsolete
(5)
View All
Add attachment
proposed patch, testcase, etc.
Aakash Jain
Comment 1
2017-02-28 12:09:44 PST
Created
attachment 302964
[details]
Proposed patch
Tim Horton
Comment 2
2017-02-28 12:12:22 PST
If nobody is depending on them should we unexport or maybe delete them?
Aakash Jain
Comment 3
2017-02-28 12:29:27 PST
Created
attachment 302967
[details]
Updated patch Yeah. Un-exporting them. They seems to be used within WebKit2, so can't delete them.
Tim Horton
Comment 4
2017-02-28 12:35:39 PST
Wait, is there other SPI that returns these? Your first patch might have been better, sorry.
Alexey Proskuryakov
Comment 5
2017-02-28 14:06:09 PST
If you look at the patch that added these, it's fairly complex. I'm not sure if it can be rolled back, but it seem preferable to roll back if it can be. The usage in WebKit may still be API related. Also, that patch first landed with a private header, broke things, and got re-landed with a project one. Need to look into was broke.
Alexey Proskuryakov
Comment 6
2017-03-02 12:30:13 PST
I now have the context for why these constants were added. They are needed for clients to identify menu items in these WebKit delegate methods: @protocol WKUIDelegatePrivate <WKUIDelegate> ... - (NSMenu *)_webView:(WKWebView *)webView contextMenu:(NSMenu *)menu forElement:(_WKContextMenuElementInfo *)element WK_API_AVAILABLE(macosx(10.12)); - (NSMenu *)_webView:(WKWebView *)webView contextMenu:(NSMenu *)menu forElement:(_WKContextMenuElementInfo *)element userInfo:(id <NSSecureCoding>)userInfo WK_API_AVAILABLE(macosx(10.12)); So it seems best to make the header private to complement that, even though the constants are still not used by anyone.
Aakash Jain
Comment 7
2017-03-02 12:34:18 PST
Created
attachment 303224
[details]
Previous patch again
Alexey Proskuryakov
Comment 8
2017-03-02 12:35:48 PST
Comment on
attachment 302964
[details]
Proposed patch View in context:
https://bugs.webkit.org/attachment.cgi?id=302964&action=review
> Source/WebKit2/ChangeLog:3 > + Make WKMenuItemIdentifiersPrivate.h private header
This initial patch looks good, but we should also clean up another change from
bug 151272
. This change is definitely not needed when using 10.12 SDK. I do not think that it is needed with 10.11 SDK either, so let's see if it can be undone. Index: /trunk/Source/WebCore/platform/spi/mac/NSMenuSPI.h =================================================================== --- /trunk/Source/WebCore/platform/spi/mac/NSMenuSPI.h (revision 192480) +++ /trunk/Source/WebCore/platform/spi/mac/NSMenuSPI.h (revision 192481) @@ -46,3 +46,6 @@ @end +@interface NSMenuItem () <NSUserInterfaceItemIdentification> +@end + #endif
Alexey Proskuryakov
Comment 9
2017-03-02 12:37:57 PST
Thinking about it a bit more, I think that it is needed with 10.11 - that's where we get setIdentifier. So let's make it conditional on __MAC_OS_X_VERSION_MAX_ALLOWED.
Aakash Jain
Comment 10
2017-03-03 18:25:51 PST
Created
attachment 303372
[details]
Updated patch
Tim Horton
Comment 11
2017-03-03 18:29:02 PST
Comment on
attachment 303372
[details]
Updated patch View in context:
https://bugs.webkit.org/attachment.cgi?id=303372&action=review
> Source/WebCore/ChangeLog:8 > + * platform/spi/mac/NSMenuSPI.h: NSMenuItem is not needed with 10.12 or greater SDK.
What? Why not? *ImmediateActionController use these, at this point I think on all platforms?
Build Bot
Comment 12
2017-03-03 21:39:22 PST
Comment on
attachment 303372
[details]
Updated patch
Attachment 303372
[details]
did not pass mac-debug-ews (mac): Output:
http://webkit-queues.webkit.org/results/3235244
New failing tests: media/modern-media-controls/media-documents/click-on-video-should-not-pause.html
Build Bot
Comment 13
2017-03-03 21:39:25 PST
Created
attachment 303383
[details]
Archive of layout-test-results from ews117 for mac-elcapitan The attached test failures were seen while running run-webkit-tests on the mac-debug-ews. Bot: ews117 Port: mac-elcapitan Platform: Mac OS X 10.11.6
Alexey Proskuryakov
Comment 14
2017-03-03 21:41:00 PST
> What? Why not?
The fact that NSMenuItem implements NSUserInterfaceItemIdentification is now in the public header.
Tim Horton
Comment 15
2017-03-03 21:43:56 PST
(In reply to
comment #14
)
> > What? Why not? > > The fact that NSMenuItem implements NSUserInterfaceItemIdentification is now > in the public header.
Ok, but the patch also removed some SPI declarations...
mitz
Comment 16
2017-03-03 21:45:14 PST
Comment on
attachment 303372
[details]
Updated patch View in context:
https://bugs.webkit.org/attachment.cgi?id=303372&action=review
> Source/WebCore/platform/spi/mac/NSMenuSPI.h:47 > +#if PLATFORM(MAC) && __MAC_OS_X_VERSION_MAX_ALLOWED < 101200
The entire header is guarded with #if PLATFORM(MAC) so this is redundant.
Alexey Proskuryakov
Comment 17
2017-03-03 21:51:52 PST
> Ok, but the patch also removed some SPI declarations...
Can you elaborate? The patch looks right to me, with the exception of the redundancy that Dan pointed out.
Tim Horton
Comment 18
2017-03-03 21:58:12 PST
(In reply to
comment #17
)
> > Ok, but the patch also removed some SPI declarations... > > Can you elaborate? > > The patch looks right to me, with the exception of the redundancy that Dan > pointed out.
There are things inside the category. Those things are still SPI. They are still used in current versions of macOS. They cannot be #if'd out. You can #if out the conformance if you want, but you'll have to move it to its own @interface.
Alexey Proskuryakov
Comment 19
2017-03-04 00:27:03 PST
Indeed, selective blindness on my part. Probably caused by the fact that the patch built (of course it did in EWS).
Aakash Jain
Comment 20
2017-03-06 13:46:17 PST
Created
attachment 303549
[details]
Updated patch
Build Bot
Comment 21
2017-03-06 14:35:03 PST
Comment on
attachment 303549
[details]
Updated patch
Attachment 303549
[details]
did not pass mac-ews (mac): Output:
http://webkit-queues.webkit.org/results/3254381
New failing tests: media/modern-media-controls/tracks-support/tracks-support-show-panel-after-dragging-controls.html
Build Bot
Comment 22
2017-03-06 14:35:07 PST
Created
attachment 303560
[details]
Archive of layout-test-results from ews101 for mac-elcapitan The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: ews101 Port: mac-elcapitan Platform: Mac OS X 10.11.6
WebKit Commit Bot
Comment 23
2017-03-06 17:39:55 PST
Comment on
attachment 303549
[details]
Updated patch Clearing flags on attachment: 303549 Committed
r213482
: <
http://trac.webkit.org/changeset/213482
>
WebKit Commit Bot
Comment 24
2017-03-06 17:40:01 PST
All reviewed patches have been landed. Closing bug.
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