The assertion that mousemove handling does not update style is wrong |
|||||
Issue descriptionThe following layout tests assert that mousemove does not perform synchronous style update: - fast/css/hover-recalc.html - fast/css/invalidation/hover-first-letter-sibling.html - fast/css/invalidation/removed-hover-shadow-rule.html - fast/css/invalidation/targeted-hover-invalidation.html mousemove handling calls EventHandler::selectAutoCursor, which calls hasEditableStyle. However, editable styles can be correctly inspected only when style is clean, which forces a style update. Hence, the above layout tests will fail once we make hasEditableStyle work correctly.
,
Nov 25 2016
Stack trace: #8 0x7fef4441cf44 blink::hasEditableStyle() #9 0x7fef4498ce35 blink::EventHandler::selectAutoCursor() #10 0x7fef4498ca10 blink::EventHandler::selectCursor() #11 0x7fef4498eaf4 blink::EventHandler::handleMouseMoveOrLeaveEvent() #12 0x7fef4498e1bd blink::EventHandler::handleMouseMoveEvent() #13 0x7fef474ad5ed blink::PageWidgetEventHandler::handleMouseMove() #14 0x7fef474ad392 blink::PageWidgetDelegate::handleInputEvent() #15 0x7fef475b0711 blink::WebViewImpl::handleInputEvent() #16 0x7fef46f0eded test_runner::EventSender::HandleInputEventOnViewOrPopup()
,
Nov 25 2016
We should postpone auto cursor calculation to the pipeline, instead of done synchronously in handleMouseMoveOrLeaveEvent.
,
Nov 25 2016
See http://crbug.com/361164 removes updateSaL().
,
Nov 25 2016
,
Jan 23 2017
,
Mar 10 2017
,
Mar 14 2017
nzolghadr@ we need to postpone adjusting the cursor it seems. Is that possible? |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by xiaoche...@chromium.org
, Nov 25 2016