Bug 185777 – Click events only fire once when editing

• Status: RESOLVED
• Resolution: FIXED
• Component: HTML Editing

[Aditya Keerthi]

Click events are only firing once on editable regions of text - this includes elements that specify contenteditable, as well as <input> elements.

[Aditya Keerthi]

<rdar://problem/9724138>

[Aditya Keerthi]

Created attachment 340726 [details]
Patch

[Wenson Hsieh]

Comment on attachment 340726 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=340726&action=review

> Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm:714
> +    if (node->document().focusedElement() == node)

We probably only want to bail here if we're also editing...

Otherwise, this means that if an element that's not in editable content already has focus, we will no longer flash the tap highlight over that node.
For instance, if you have a <button id='button'> and call button.focus(), we should still see the tap highlight over the button if you tap on it. Perhaps we could check if m_assistedNode == node instead?

[Wenson Hsieh]

Comment on attachment 340726 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=340726&action=review

>> Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm:714
>> +    if (node->document().focusedElement() == node)
> 
> We probably only want to bail here if we're also editing...
> 
> Otherwise, this means that if an element that's not in editable content already has focus, we will no longer flash the tap highlight over that node.
> For instance, if you have a <button id='button'> and call button.focus(), we should still see the tap highlight over the button if you tap on it. Perhaps we could check if m_assistedNode == node instead?

Actually, checking against m_assistedNode is probably still won't work in the case of editable elements that have been programmatically focused (select, input, textarea, etc.) prior to the tap...

We really only want to suppress the tap highlight if we've tapped inside a node that is assisted in the UI process (i.e. the keyboard is up and the selection assistant is active).

[Aditya Keerthi]

We also have m_isAssistingNodeDueToUserInteraction in the WebProcess. I'm going to see if I can use that.

[Aditya Keerthi]

Created attachment 340738 [details]
Patch

[Aditya Keerthi]

Wenson pointed out that we can't use m_isAssistingNodeDueToUserInteraction in order to bail out of highlighting, due to a corner case.

Clients that implement _webView:focusShouldStartInputSession: can programmatically focus editable elements and show the keyboard. This would result in m_isAssistingNodeDueToUserInteraction remaining false, and a tap highlight showing if a user were to tap on the element while editing.

For this reason, I have moved the tap highlight check to the UIProcess.

[Tim Horton]

Comment on attachment 340738 [details]
Patch

Megan and I looked at this together.

[WebKit Commit Bot]

Comment on attachment 340738 [details]
Patch

Clearing flags on attachment: 340738

Committed r232040: <https://trac.webkit.org/changeset/232040>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.