RESOLVED FIXED168981
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
Updated patch (5.29 KB, patch)
2017-02-28 12:29 PST, Aakash Jain
ap: review-
Previous patch again (2.39 KB, patch)
2017-03-02 12:34 PST, Aakash Jain
no flags
Updated patch (3.55 KB, patch)
2017-03-03 18:25 PST, Aakash Jain
thorton: review-
buildbot: commit-queue-
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
Updated patch (3.61 KB, patch)
2017-03-06 13:46 PST, Aakash Jain
no flags
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
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.