WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
179714
[Touch Bar Web API] Object representing Touch Bar Menu to send between Web and UI Processes
https://bugs.webkit.org/show_bug.cgi?id=179714
Summary
[Touch Bar Web API] Object representing Touch Bar Menu to send between Web an...
Aishwarya Nirmal
Reported
2017-11-14 18:05:11 PST
This change defines an object that contains data for the touch bar menu, and the information stored in this object will be obtained from attributes in the menu and menuitem html elements that represent the touch bar. This object will be sent between the web and ui processes.
Attachments
Patch
(39.07 KB, patch)
2017-11-14 18:45 PST
,
Aishwarya Nirmal
no flags
Details
Formatted Diff
Diff
Patch
(28.47 KB, patch)
2017-11-15 10:54 PST
,
Aishwarya Nirmal
no flags
Details
Formatted Diff
Diff
Patch
(38.93 KB, patch)
2017-11-15 11:05 PST
,
Aishwarya Nirmal
no flags
Details
Formatted Diff
Diff
Archive of layout-test-results from ews102 for mac-elcapitan
(2.30 MB, application/zip)
2017-11-15 11:58 PST
,
Build Bot
no flags
Details
Archive of layout-test-results from ews106 for mac-elcapitan-wk2
(2.83 MB, application/zip)
2017-11-15 12:17 PST
,
Build Bot
no flags
Details
Archive of layout-test-results from ews121 for ios-simulator-wk2
(20.36 MB, application/zip)
2017-11-15 13:28 PST
,
Build Bot
no flags
Details
Patch
(38.98 KB, patch)
2017-11-15 13:43 PST
,
Aishwarya Nirmal
no flags
Details
Formatted Diff
Diff
Patch
(42.07 KB, patch)
2017-11-16 16:57 PST
,
Aishwarya Nirmal
no flags
Details
Formatted Diff
Diff
Patch
(41.34 KB, patch)
2017-11-16 17:56 PST
,
Aishwarya Nirmal
no flags
Details
Formatted Diff
Diff
Patch
(41.51 KB, patch)
2017-11-17 08:53 PST
,
Aishwarya Nirmal
no flags
Details
Formatted Diff
Diff
Patch
(41.61 KB, patch)
2017-11-17 09:08 PST
,
Aishwarya Nirmal
no flags
Details
Formatted Diff
Diff
Patch
(41.54 KB, patch)
2017-11-17 10:54 PST
,
Aishwarya Nirmal
no flags
Details
Formatted Diff
Diff
Patch
(41.76 KB, patch)
2017-11-17 11:51 PST
,
Aishwarya Nirmal
no flags
Details
Formatted Diff
Diff
Patch
(41.75 KB, patch)
2017-11-17 12:14 PST
,
Aishwarya Nirmal
no flags
Details
Formatted Diff
Diff
Patch
(41.75 KB, patch)
2017-11-27 14:53 PST
,
Aishwarya Nirmal
no flags
Details
Formatted Diff
Diff
Patch
(41.79 KB, patch)
2017-11-27 15:13 PST
,
Aishwarya Nirmal
no flags
Details
Formatted Diff
Diff
Patch
(41.61 KB, patch)
2017-11-27 15:39 PST
,
Aishwarya Nirmal
no flags
Details
Formatted Diff
Diff
Patch
(41.59 KB, patch)
2017-11-27 16:10 PST
,
Aishwarya Nirmal
no flags
Details
Formatted Diff
Diff
Patch
(42.08 KB, patch)
2017-11-27 16:32 PST
,
Aishwarya Nirmal
no flags
Details
Formatted Diff
Diff
Patch
(41.61 KB, patch)
2017-11-27 16:44 PST
,
Aishwarya Nirmal
no flags
Details
Formatted Diff
Diff
Patch
(42.11 KB, patch)
2017-11-27 18:24 PST
,
Aishwarya Nirmal
no flags
Details
Formatted Diff
Diff
Patch
(41.64 KB, patch)
2017-11-28 10:58 PST
,
Aishwarya Nirmal
no flags
Details
Formatted Diff
Diff
Patch
(40.71 KB, patch)
2017-11-28 13:20 PST
,
Aishwarya Nirmal
no flags
Details
Formatted Diff
Diff
Patch
(39.88 KB, patch)
2017-11-29 10:20 PST
,
Aishwarya Nirmal
no flags
Details
Formatted Diff
Diff
Show Obsolete
(20)
View All
Add attachment
proposed patch, testcase, etc.
Aishwarya Nirmal
Comment 1
2017-11-14 18:45:33 PST
Created
attachment 326957
[details]
Patch
Aishwarya Nirmal
Comment 2
2017-11-15 10:54:11 PST
Created
attachment 326997
[details]
Patch
Aishwarya Nirmal
Comment 3
2017-11-15 11:05:30 PST
Created
attachment 326998
[details]
Patch
Build Bot
Comment 4
2017-11-15 11:58:04 PST
Comment on
attachment 326998
[details]
Patch
Attachment 326998
[details]
did not pass mac-ews (mac): Output:
http://webkit-queues.webkit.org/results/5248702
New failing tests: fast/events/tabindex-focus-blur-all.html imported/w3c/web-platform-tests/html/dom/reflection-misc.html
Build Bot
Comment 5
2017-11-15 11:58:06 PST
Created
attachment 327006
[details]
Archive of layout-test-results from ews102 for mac-elcapitan The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: ews102 Port: mac-elcapitan Platform: Mac OS X 10.11.6
Build Bot
Comment 6
2017-11-15 12:17:57 PST
Comment on
attachment 326998
[details]
Patch
Attachment 326998
[details]
did not pass mac-wk2-ews (mac-wk2): Output:
http://webkit-queues.webkit.org/results/5248816
New failing tests: fast/events/tabindex-focus-blur-all.html imported/w3c/web-platform-tests/html/dom/reflection-misc.html
Build Bot
Comment 7
2017-11-15 12:17:59 PST
Created
attachment 327010
[details]
Archive of layout-test-results from ews106 for mac-elcapitan-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: ews106 Port: mac-elcapitan-wk2 Platform: Mac OS X 10.11.6
Build Bot
Comment 8
2017-11-15 13:28:47 PST
Comment on
attachment 326998
[details]
Patch
Attachment 326998
[details]
did not pass ios-sim-ews (ios-simulator-wk2): Output:
http://webkit-queues.webkit.org/results/5249433
New failing tests: imported/w3c/web-platform-tests/html/dom/reflection-misc.html
Build Bot
Comment 9
2017-11-15 13:28:49 PST
Created
attachment 327014
[details]
Archive of layout-test-results from ews121 for ios-simulator-wk2 The attached test failures were seen while running run-webkit-tests on the ios-sim-ews. Bot: ews121 Port: ios-simulator-wk2 Platform: Mac OS X 10.12.6
Ryosuke Niwa
Comment 10
2017-11-15 13:34:04 PST
Comment on
attachment 326998
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=326998&action=review
> Source/WebCore/html/HTMLMenuElement.cpp:44 > + if (auto* page = document().page()) > + page->chrome().client().didInsertMenuElement(*this);
This code is almost certainly wrong. This function gets called whenever a this menu element is inserted into some ancestor regardless of whether it's in a document or not. You need to check type to see if it's in the document or not. It's very important that didInsertMenuElement never tries to execute any scripts. Are you sure this new ChromeClient callback wouldn't do that?
> Source/WebCore/html/HTMLMenuElement.cpp:54 > + page->chrome().client().didRemoveMenuElement(*this);
Ditto.
> Source/WebCore/html/HTMLMenuElement.cpp:66 > + bool oldIsTouchBarMenu = m_isTouchBarMenu;
We usually call this variable wasTouchBarMenu
> Source/WebCore/html/HTMLMenuElement.cpp:70 > + if (!RuntimeEnabledFeatures::sharedFeatures().menuItemElementEnabled() || !m_initialTypeAttributeParsed) > + m_initialTypeAttributeParsed = true; > + else {
Why is the initial attribute value important? I don't think it makes sense to lock the type of an element like that. It's more natural that changing the type value would change the semantics of the element (like when you removed an menu element).
> Source/WebCore/html/HTMLMenuItemElement.cpp:45 > + if (auto* page = document().page()) > + page->chrome().client().didInsertMenuItemElement(*this);
Ditto. This code is almost certainly wrong. You should run this code only when the node is newly connected to a document, and we need to make sure didInsertMenuItemElement callback doesn't try to execute any scripts or otherwise callback into WebKit to do so.
> Source/WebCore/html/HTMLMenuItemElement.cpp:52 > + if (auto* page = document().page())
Ditto.
> Source/WebCore/html/HTMLMenuItemElement.cpp:76 > + if (name == typeAttr) > + m_type = value; > + else if (name == idAttr) > + m_identifier = value; > + else if (name == hiddenAttr) > + m_visible = !equalLettersIgnoringASCIICase(value, "true"); > + else if (name == titleAttr) > + m_customizationLabel = value; > + else if (name == onclickAttr) > + m_commandName = value; > + else if (name == srcAttr) > + m_viewReference = value; > + else if (name == valueAttr) > + m_priority = value.toFloat();
What's the point of storing all these values in a member variable. We can just get the value and covert on demand via getAttribute. r- because we shouldn't be making copies of content attributes like this.
> Source/WebKit/Shared/TouchBarMenuData.cpp:47 > + , identifier("") > + , visible(false) > + , viewRef("") > + , commandName("") > + , customizationLabel("")
No need to initialize strings like this. They're initialized to empty string by default.
> Source/WebKit/Shared/TouchBarMenuData.cpp:125 > +inline bool operator< (const TouchBarMenuItemData lhs, TouchBarMenuItemData rhs)
Nit: we don't put a space after operator< like this.
> Source/WebKit/Shared/TouchBarMenuData.cpp:130 > +inline bool operator> (const TouchBarMenuItemData lhs, TouchBarMenuItemData rhs)
Ditto. The space between operator< and ( should be removed.
> Source/WebKit/Shared/TouchBarMenuData.cpp:135 > +inline bool operator<= (const TouchBarMenuItemData lhs, TouchBarMenuItemData rhs)
Ditto.
> Source/WebKit/Shared/TouchBarMenuData.cpp:140 > +inline bool operator>= (const TouchBarMenuItemData lhs, TouchBarMenuItemData rhs)
Ditto.
> Source/WebKit/Shared/TouchBarMenuData.cpp:145 > +inline bool operator== (const TouchBarMenuItemData lhs, TouchBarMenuItemData rhs)
Ditto.
> Source/WebKit/Shared/TouchBarMenuData.cpp:156 > +inline bool operator!= (const TouchBarMenuItemData lhs, TouchBarMenuItemData rhs)
Ditto.
> Source/WebKit/Shared/TouchBarMenuData.cpp:209 > +Vector<TouchBarMenuItemData> TouchBarMenuData::items() > +{ > + return m_items; > +} > + > +void TouchBarMenuData::setID(String id) > +{ > + m_id = id; > +}
We're better of inlining these one-line functions in the header files.
> Source/WebKit/Shared/TouchBarMenuData.h:39 > +class TouchBarMenuItemData { > +public:
Nit: need a black line after namespace WebKit {. Since everything in this class is public, it's more appropriate to use struct.
> Source/WebKit/Shared/TouchBarMenuData.h:56 > + WEBCORE_EXPORT ~TouchBarMenuItemData();
The default destructor is sufficient. We usually add an empty destructor in CPP file to avoid #include in header files since the default constructor must be able to invoke destructors of member variables. However, here, all member variables are of POD types or String, and none of them require additional header files to be included.
> Source/WebKit/Shared/TouchBarMenuData.h:71 > +private:
If there are no private members, we should get rid of this private access specifier.
> Source/WebKit/WebProcess/WebPage/WebPage.cpp:5378 > + m_currTouchBarMenuData = *(new TouchBarMenuData());
r- this leaks TouchBarMenuData. Since m_currTouchBarMenuData is of type TouchBarMenuData, this code would simply construct a new instance of TouchBarMenuData, then assign its value to m_currTouchBarMenuData. Also, please don't abbreviate current as curr.
> Source/WebKit/WebProcess/WebPage/WebPage.cpp:5388 > + TouchBarMenuData* data = new TouchBarMenuData(element); > + m_currTouchBarMenuData = *data; > + send(Messages::WebPageProxy::TouchBarMenuDataChanged(*data), pageID(), IPC::SendOption::DispatchMessageEvenWhenWaitingForSyncReply);
Again, this leaks the TouchBarMenuData created at line 5386 for no good reason. Since you're encoding the entire object, what is the point of keeping it in the web content process? Can't we just send it to UI process without storing it in WebContent process?
> Source/WebKit/WebProcess/WebPage/WebPage.cpp:5398 > + TouchBarMenuItemData* data = new TouchBarMenuItemData(element); > + m_currTouchBarMenuData.addMenuItem(*data); > + send(Messages::WebPageProxy::TouchBarMenuDataChanged(m_currTouchBarMenuData), pageID(), IPC::SendOption::DispatchMessageEvenWhenWaitingForSyncReply);
Ditto.
> Source/WebKit/WebProcess/WebPage/WebPage.cpp:5407 > + TouchBarMenuItemData* data = new TouchBarMenuItemData(element); > + m_currTouchBarMenuData.removeMenuItem(*data); > + send(Messages::WebPageProxy::TouchBarMenuDataChanged(m_currTouchBarMenuData), pageID(), IPC::SendOption::DispatchMessageEvenWhenWaitingForSyncReply);
Ditto.
Aishwarya Nirmal
Comment 11
2017-11-15 13:43:33 PST
Created
attachment 327018
[details]
Patch
Wenson Hsieh
Comment 12
2017-11-15 21:52:06 PST
Comment on
attachment 327018
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=327018&action=review
(just some minor nits here and there)
> Source/WebCore/html/HTMLMenuElement.cpp:86 > + HTMLElement::parseAttribute(name, value);
We typically prefer early returns to if-else, so this would be something like: if (name != typeAttr) { HTMLElement::parseAttribute(name, value); return; } ...rest of logic...
> Source/WebKit/Shared/TouchBarMenuData.cpp:37 > +#include <vector>
I don't think we need to include <vector>...unless we're using the standard library vector instead of WTF's Vector somewhere here?
> Source/WebKit/Shared/TouchBarMenuData.cpp:42 > + : itemType(ItemType::Button)
You can initialize these members directly in the header, e.g. by doing `ItemType itemType { ItemType::Button };`.
> Source/WebKit/Shared/TouchBarMenuData.cpp:43 > + , identifier("")
Do these need to be initialized to the empty string, or is null String (i.e. the result of the default String() constructor) sufficient? If null strings are okay, these will be implicitly initialized to the value of String() by default, so we shouldn't need to explicitly set their values.
> Source/WebKit/Shared/TouchBarMenuData.cpp:120 > + // default button
Comments in WebKit code should begin with a capital and end with a period (for reference, here's the style guide:
https://webkit.org/code-style-guidelines/
)
> Source/WebKit/Shared/TouchBarMenuData.cpp:124 > +// Touch Bar Menu Items will be ordered based on priority
This comment should end with a period.
> Source/WebKit/Shared/TouchBarMenuData.cpp:125 > +inline bool operator< (const TouchBarMenuItemData lhs, TouchBarMenuItemData rhs)
Extra space between < and (.
> Source/WebKit/Shared/TouchBarMenuData.cpp:162 > + : m_items()
m_items will be initialized to an empty vector by default, so we won't need this here.
> Source/WebKit/Shared/TouchBarMenuData.cpp:186 > +TouchBarMenuData* TouchBarMenuData::copy() const
Hm...do we need this method? I don't see it being used anywhere else in this patch.
> Source/WebKit/Shared/TouchBarMenuData.cpp:191 > +void TouchBarMenuData::addMenuItem(TouchBarMenuItemData data)
This should probably be (const TouchBarMenuItemData& data)
> Source/WebKit/Shared/TouchBarMenuData.cpp:196 > +void TouchBarMenuData::removeMenuItem(TouchBarMenuItemData data)
const TouchBarMenuItemData& data
> Source/WebKit/Shared/TouchBarMenuData.cpp:206 > +void TouchBarMenuData::setID(String id)
(const String& id)
> Source/WebKit/Shared/TouchBarMenuData.h:42 > + CandidateList,
Interesting! I'm not sure we want to support all of these item types though...perhaps we should just limit it to buttons and maybe popover items for now? We can always add more touch bar item types here as we expose richer customization options to web content.
> Source/WebKit/WebProcess/WebPage/WebPage.cpp:5386 > + TouchBarMenuData* data = new TouchBarMenuData(element);
I'm not sure we need to allocate this TouchBarMenuData on the heap...can we just do something like: m_currTouchBarMenuData = { element }; send(Messages::WebPageProxy::TouchBarMenuDataChanged(m_currTouchBarMenuData));
> Source/WebKit/WebProcess/WebPage/WebPage.cpp:5396 > + TouchBarMenuItemData* data = new TouchBarMenuItemData(element);
Same here, we should just be able to do something like: TouchBarMenuItemData data { element }; m_currTouchBarMenuData.addMenuItem(data); send(Messages::WebPageProxy::TouchBarMenuDataChanged(m_currTouchBarMenuData));
> Source/WebKit/WebProcess/WebPage/WebPage.cpp:5405 > + TouchBarMenuItemData* data = new TouchBarMenuItemData(element);
Ditto, let's create this on the stack instead.
> Source/WebKit/WebProcess/WebPage/WebPage.h:1615 > + TouchBarMenuData m_currTouchBarMenuData;
We generally use full words instead of abbreviations, so this should probably be m_currentTouchBarMenuData; (you can refer to WebKit style guidelines for more information:
https://webkit.org/code-style-guidelines/
)
Wenson Hsieh
Comment 13
2017-11-15 22:00:56 PST
(In reply to Ryosuke Niwa from
comment #10
)
> Comment on
attachment 326998
[details]
> Patch > > View in context: >
https://bugs.webkit.org/attachment.cgi?id=326998&action=review
> > > Source/WebCore/html/HTMLMenuElement.cpp:44 > > + if (auto* page = document().page()) > > + page->chrome().client().didInsertMenuElement(*this); > > This code is almost certainly wrong. This function gets called whenever a > this menu element is inserted into some ancestor > regardless of whether it's in a document or not. You need to check type to > see if it's in the document or not.
+1
> It's very important that didInsertMenuElement never tries to execute any > scripts.
Indeed!
> Are you sure this new ChromeClient callback wouldn't do that?
The purpose of these ChromeClient callbacks should just be to grab some (non-layout-dependent) information out of the element and send it over to the UI process, so I think we should be okay...we just need to be careful we don't ask the HTMLMenuElement or HTMLMenuItemElement any questions that trigger layout :/
Aishwarya Nirmal
Comment 14
2017-11-16 16:57:30 PST
Created
attachment 327130
[details]
Patch
Wenson Hsieh
Comment 15
2017-11-16 17:11:29 PST
Comment on
attachment 327130
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=327130&action=review
> Source/WebCore/html/HTMLMenuElement.cpp:69 > + if (!RuntimeEnabledFeatures::sharedFeatures().menuItemElementEnabled())
I think we'd still want to defer to the superclass' implementation by calling HTMLElement::parseAttribute(name, value), in the case where the menu item element isn't enabled...unless there's good reason we should skip the super call in this case? If not, let's fold this `!RuntimeEnabledFeatures::sharedFeatures().menuItemElementEnabled()` check in with the early return above, so we bail `if (name != typeAttr || !RuntimeEnabledFeatures::sharedFeatures().menuItemElementEnabled())`.
> Source/WebCore/html/HTMLMenuElement.h:33 > + InsertedIntoAncestorResult insertedIntoAncestor(InsertionType, ContainerNode&) final;
We usually make these private instead of public.
> Source/WebKit/Shared/TouchBarMenuData.cpp:41 > + : m_items()
Nit - We don't need to explicitly initialize this, since it'll be initialized to an empty vector by default.
> Source/WebKit/Shared/TouchBarMenuData.cpp:42 > + , m_isPageCustomized(false)
Nit - We typically initialize these in the header file (e.g. bool m_isPageCustomized { false };)
> Source/WebKit/Shared/TouchBarMenuData.cpp:65 > +void TouchBarMenuData::addMenuItem(const TouchBarMenuItemData data)
const reference! (const TouchBarMenuItemData&)
> Source/WebKit/Shared/TouchBarMenuData.cpp:70 > +void TouchBarMenuData::removeMenuItem(const TouchBarMenuItemData data)
This should be a const reference (const TouchBarMenuItemData&)
> Source/WebKit/Shared/TouchBarMenuItemData.cpp:62 > + : itemType(ItemType::Button)
These should be initialized in the header (e.g. ItemType itemType { ItemType::Button };)
> Source/WebKit/WebProcess/WebPage/WebPage.cpp:5382 > + send(Messages::WebPageProxy::TouchBarMenuDataChanged(temp), pageID(), IPC::SendOption::DispatchMessageEvenWhenWaitingForSyncReply);
I don't think we'll need to use the DispatchMessageEvenWhenWaitingForSyncReply option for these IPC message sends...
Aishwarya Nirmal
Comment 16
2017-11-16 17:56:04 PST
Created
attachment 327138
[details]
Patch
Aishwarya Nirmal
Comment 17
2017-11-17 08:53:57 PST
Created
attachment 327176
[details]
Patch
Aishwarya Nirmal
Comment 18
2017-11-17 09:08:44 PST
Created
attachment 327180
[details]
Patch
Aishwarya Nirmal
Comment 19
2017-11-17 10:54:10 PST
Created
attachment 327196
[details]
Patch
Aishwarya Nirmal
Comment 20
2017-11-17 11:51:47 PST
Created
attachment 327207
[details]
Patch
Aishwarya Nirmal
Comment 21
2017-11-17 12:14:09 PST
Created
attachment 327211
[details]
Patch
Ryosuke Niwa
Comment 22
2017-11-20 16:59:47 PST
Comment on
attachment 327211
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=327211&action=review
> Source/WebCore/html/HTMLMenuElement.cpp:43 > +#if PLATFORM(COCOA)
I don't think we want to guard this behind PLATFORM(COCOA). There is no reason these code need to be COCOA specific beyond menuItemElementEnabled() check. In general, we should try avoiding adding if PLATFORM(~) in WebCore because it increases the cognitive stress for people reading the code. It's much simpler to see the code as a runtime enabled feature.
> Source/WebCore/html/HTMLMenuElement.cpp:75 > + for (Node* node = firstChild(); node; node = node->nextSibling()) { > + if (!is<HTMLMenuItemElement>(node))
Use childrenOfType<HTMLMenuItemElement> instead.
> Source/WebCore/html/HTMLMenuItemElement.cpp:50 > + if (type.connectedToDocument) { > + if (auto* page = document().page())
Don't we need to check that the parent node is a HTMLMenuElement here?
> Source/WebCore/html/HTMLMenuItemElement.cpp:60 > + if (auto* page = document().page())
Do we need to check that the parent was a HTMLMenuElement here?
> Source/WebKit/Shared/TouchBarMenuData.h:44 > + TouchBarMenuData(); > + TouchBarMenuData(WebCore::HTMLMenuElement&); > + TouchBarMenuData(const TouchBarMenuData&);
Please make these constructors explicit. Otherwise, we may accidentally create TouchBarMenuData from HTMLMenuElement/TouchBarMenuData in implicit coercion.
> Source/WebKit/Shared/TouchBarMenuData.h:46 > + WEBCORE_EXPORT ~TouchBarMenuData();
As I stated in the previous patch, I don't think there is any need to define an explicit destructor. Inlining it here should work just fine.
> Source/WebKit/Shared/TouchBarMenuItemData.h:55 > + TouchBarMenuItemData(); > + TouchBarMenuItemData(WebCore::HTMLMenuItemElement&); > + TouchBarMenuItemData(const TouchBarMenuItemData&);
Ditto to make these constructors explicit.
Wenson Hsieh
Comment 23
2017-11-27 13:10:49 PST
Comment on
attachment 327211
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=327211&action=review
>> Source/WebCore/html/HTMLMenuElement.cpp:43 >> +#if PLATFORM(COCOA) > > I don't think we want to guard this behind PLATFORM(COCOA). > There is no reason these code need to be COCOA specific beyond menuItemElementEnabled() check. > In general, we should try avoiding adding if PLATFORM(~) in WebCore > because it increases the cognitive stress for people reading the code. > It's much simpler to see the code as a runtime enabled feature.
I think making just the touch-bar-specific bits in WebKit fall under PLATFORM(MAC) or PLATFORM(COCOA) is sensible. I agree, the menu/menuitem element code in WebCore should definitely be platform agnostic.
>> Source/WebKit/Shared/TouchBarMenuData.h:46 >> + WEBCORE_EXPORT ~TouchBarMenuData(); > > As I stated in the previous patch, I don't think there is any need to define an explicit destructor. > Inlining it here should work just fine.
Also, I don't think we need to export this destructor.
Aishwarya Nirmal
Comment 24
2017-11-27 14:53:58 PST
Created
attachment 327686
[details]
Patch
Aishwarya Nirmal
Comment 25
2017-11-27 15:13:35 PST
Created
attachment 327693
[details]
Patch
Aishwarya Nirmal
Comment 26
2017-11-27 15:39:18 PST
Created
attachment 327700
[details]
Patch
Aishwarya Nirmal
Comment 27
2017-11-27 16:10:38 PST
Created
attachment 327709
[details]
Patch
Aishwarya Nirmal
Comment 28
2017-11-27 16:32:27 PST
Created
attachment 327710
[details]
Patch
Aishwarya Nirmal
Comment 29
2017-11-27 16:44:52 PST
Created
attachment 327712
[details]
Patch
Aishwarya Nirmal
Comment 30
2017-11-27 18:24:12 PST
Created
attachment 327720
[details]
Patch
Aishwarya Nirmal
Comment 31
2017-11-28 10:58:00 PST
Created
attachment 327765
[details]
Patch
Aishwarya Nirmal
Comment 32
2017-11-28 13:20:37 PST
Created
attachment 327780
[details]
Patch
Wenson Hsieh
Comment 33
2017-11-28 17:20:15 PST
Comment on
attachment 327780
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=327780&action=review
> Source/WebKit/Shared/TouchBarMenuData.h:48 > + Vector<TouchBarMenuItemData> items() { return m_items; }
This seems like this should be const Vector<TouchBarMenuItemData>&.
> Source/WebKit/Shared/TouchBarMenuItemData.h:59 > + String customizationLabel;
The customizationLabel is the text that's shown when customizing the items on the touch bar via View > Customize Touch Bar…. It looks like this is set to the value of the menu item's title attribute, however — perhaps this could just be label?
> Source/WebKit/Shared/TouchBarMenuItemData.h:60 > + float priority { 0.0 };
I would prefer to pare down this list of member variables, so that we only add what we'll need in this patch and the next.
Aishwarya Nirmal
Comment 34
2017-11-29 10:20:29 PST
Created
attachment 327868
[details]
Patch
WebKit Commit Bot
Comment 35
2017-12-01 17:38:54 PST
Comment on
attachment 327868
[details]
Patch Clearing flags on attachment: 327868 Committed
r225438
: <
https://trac.webkit.org/changeset/225438
>
WebKit Commit Bot
Comment 36
2017-12-01 17:38:56 PST
All reviewed patches have been landed. Closing bug.
Radar WebKit Bug Importer
Comment 37
2017-12-01 17:41:27 PST
<
rdar://problem/35810449
>
Daniel Bates
Comment 38
2017-12-01 22:19:27 PST
Comment on
attachment 327868
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=327868&action=review
> Source/WebKit/Shared/TouchBarMenuData.cpp:33 > +#include <WebCore/HTMLElement.h>
It is unnecessary to include this header because HTMLMenuElement.h (below) will include it.
> Source/WebKit/Shared/TouchBarMenuData.cpp:36 > +#include <WebCore/Node.h>
Ditto.
> Source/WebKit/Shared/TouchBarMenuData.cpp:40 > +TouchBarMenuData::TouchBarMenuData()
It is sufficient to use = default: TouchMenuBarData::TouchBarMenuData() = default;
> Source/WebKit/Shared/TouchBarMenuData.cpp:48 > + m_id = element.attributeWithoutSynchronization(WebCore::HTMLNames::idAttr);
We are not making use of m_id in this patch. I take it you plan to make use of it in a follow up?
> Source/WebKit/Shared/TouchBarMenuData.cpp:76 > + if (!decoder.decode(data.m_items))
I would have written this body in one line: return decoder.decode(data.m_items);
> Source/WebKit/Shared/TouchBarMenuData.h:29 > +#include <WebCore/HTMLMenuElement.h>
It is unnecessary to include this header. It is sufficient to forward declare HTMLMenuElement.
> Source/WebKit/Shared/TouchBarMenuData.h:53 > + void setID(String);
This member function is never defined. Do we still need this function? Do you plan to implement in a follow up? If not, then please remove.
> Source/WebKit/Shared/TouchBarMenuItemData.cpp:44 > +TouchBarMenuItemData::TouchBarMenuItemData()
Please default this constructor. See my remark in file TouchBarMenuData.cpp for an example.
> Source/WebKit/Shared/TouchBarMenuItemData.cpp:56 > +TouchBarMenuItemData::TouchBarMenuItemData(const TouchBarMenuItemData& other)
Is it necessary that this copy constructor be explicit? If so, the. Please “= default” this function (see my remark above about doing the same for the constructor). Otherwise, remove this implementation and the declaration for it and let the compiler generate this for us.
> Source/WebKit/UIProcess/WebPageProxy.messages.in:317 > +
I do not see the need to add this empty line. One empty line is sufficient to demarcate the section above from this code.
Wenson Hsieh
Comment 39
2017-12-01 22:22:15 PST
(In reply to Daniel Bates from
comment #38
)
> Comment on
attachment 327868
[details]
> Patch > > View in context: >
https://bugs.webkit.org/attachment.cgi?id=327868&action=review
> > > Source/WebKit/Shared/TouchBarMenuData.cpp:33 > > +#include <WebCore/HTMLElement.h> > > It is unnecessary to include this header because HTMLMenuElement.h (below) > will include it. > > > Source/WebKit/Shared/TouchBarMenuData.cpp:36 > > +#include <WebCore/Node.h> > > Ditto. > > > Source/WebKit/Shared/TouchBarMenuData.cpp:40 > > +TouchBarMenuData::TouchBarMenuData() > > It is sufficient to use = default: > > TouchMenuBarData::TouchBarMenuData() = default; > > > Source/WebKit/Shared/TouchBarMenuData.cpp:48 > > + m_id = element.attributeWithoutSynchronization(WebCore::HTMLNames::idAttr); > > We are not making use of m_id in this patch. I take it you plan to make use > of it in a follow up? > > > Source/WebKit/Shared/TouchBarMenuData.cpp:76 > > + if (!decoder.decode(data.m_items)) > > I would have written this body in one line: > > return decoder.decode(data.m_items); > > > Source/WebKit/Shared/TouchBarMenuData.h:29 > > +#include <WebCore/HTMLMenuElement.h> > > It is unnecessary to include this header. It is sufficient to forward > declare HTMLMenuElement. > > > Source/WebKit/Shared/TouchBarMenuData.h:53 > > + void setID(String); > > This member function is never defined. Do we still need this function? Do > you plan to implement in a follow up? If not, then please remove. > > > Source/WebKit/Shared/TouchBarMenuItemData.cpp:44 > > +TouchBarMenuItemData::TouchBarMenuItemData() > > Please default this constructor. See my remark in file TouchBarMenuData.cpp > for an example. > > > Source/WebKit/Shared/TouchBarMenuItemData.cpp:56 > > +TouchBarMenuItemData::TouchBarMenuItemData(const TouchBarMenuItemData& other) > > Is it necessary that this copy constructor be explicit? If so, the. Please > “= default” this function (see my remark above about doing the same for the > constructor). Otherwise, remove this implementation and the declaration for > it and let the compiler generate this for us. > > > Source/WebKit/UIProcess/WebPageProxy.messages.in:317 > > + > > I do not see the need to add this empty line. One empty line is sufficient > to demarcate the section above from this code.
I'm tracking cleanup with a followup bug here:
https://bugs.webkit.org/show_bug.cgi?id=180305
. Some of our comments overlap — I'll adjust for your review feedback as well.
Wenson Hsieh
Comment 40
2017-12-01 22:38:13 PST
Comment on
attachment 327868
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=327868&action=review
>> Source/WebKit/Shared/TouchBarMenuData.cpp:48 >> + m_id = element.attributeWithoutSynchronization(WebCore::HTMLNames::idAttr); > > We are not making use of m_id in this patch. I take it you plan to make use of it in a follow up?
Aishwarya is planning to make use of it in a followup, though this may change. This is a work in progress patch, so there are going to be a few methods and interfaces we define and implement but don't use until the next patch in the sequence.
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