[Webkit-unassigned] [Bug 191715] New: Caret stops blinking after context menu shown

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=191715

            Bug ID: 191715
           Summary: Caret stops blinking after context menu shown
           Product: WebKit
           Version: WebKit Local Build
          Hardware: All
                OS: All
            Status: NEW
          Severity: Minor
          Priority: P2
         Component: HTML Editing
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: jonathan at e3software.com
                CC: wenson_hsieh at apple.com

Showing a context menu for a selection of text inside of a contenteditable element stops the caret from blinking even *after* the context menu is dismissed. The only way to restart the blinking after the menu is dismissed is to click somewhere else inside the contenteditable element. If you don’t click and instead use the keyboard to change the selection, the caret will remain unblinking.

FrameSelection::setCaretBlinkingSuspended(true) is called from EventHandler::handleMousePressEvent(). The balancing setCaretBlinkingSuspended(false) call is found in EventHandler::handleMouseReleaseEvent. The reason it is broken in the case of context menus is because handleMouseReleaseEvent is never called after the context menu is shown.

My proposed fix is to modify EventHandler::sendContextMenuEvent and have it call setCaretBlinkingSuspended(false) before showing the menu. I can create a patch, but wanted to ask first if it is feasible to create a layout regression test to cover this bug/fix? I can’t think of an obvious way to do it.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20181115/9fea2b27/attachment.html>