haikuwebkit/LayoutTests/tiled-drawing/scrolling/scroll-iframe-latched-selec...

16 lines
662 B
Plaintext
Raw Permalink Normal View History

Wheel events' latching state is not reset when appropriate https://bugs.webkit.org/show_bug.cgi?id=155746 Reviewed by Simon Fraser. Source/WebCore: When one performs a two fingers scroll (with trackpad), it might either trigger a kinetic scroll movement (by flickering with both fingers in a given direction) or perform a static scroll movement (without the flicker animation). In case of the first scenario (kinetic), the container being scrolled is "latched" during the scroll animation and properly unlatched once the scroll ends. See the call to 'shouldResetLatching' in EventHandlerMac.mm. When transitioning from non-momentum to momentum scroll, the following events are seen: - 'phase PlatformWheelEventPhaseEnded' 'momentumPhase PlatformWheelEventPhaseNone' -> end of static scroll - 'phase PlatformWheelEventPhaseNone' 'momentumPhase PlatformWheelEventPhaseBegan' -> start of momentum scroll On the second scenario (static scroll), when the scroll movement ends, the latched state is not reset. This might actually cause scrolling elsewhere on the page to scroll the previously latched container. Note that, only specific wheel event below is fired when static scroll ends: - 'phase PlatformWheelEventPhaseEnded' 'momentumPhase PlatformWheelEventPhaseNone' In order to fix this, patch installs a timer as soon as a non-momentum wheel scroll event end fires. It works as follows: - If the timer fires, the latched state is reset, preventing scrolling getting stuck to a previously latched scrollable. - If platform code starts sending momentum wheel scroll events before it times out, the timer is stopped and the latched state remains untouched (this is a flick scroll case). - If a new wheel scroll gesture starts, the latched state is manually reset and the timer stopped. Note that given that latched state logic applies primarily to main frames, the timer only gets manipulated for main frame objects. Test: tiled-drawing/scrolling/scroll-iframe-latched-selects.html * page/EventHandler.cpp: (WebCore::EventHandler::doOrScheduleClearLatchedStateIfNeeded): * page/EventHandler.h: * page/MainFrame.cpp: (WebCore::MainFrame::MainFrame): (WebCore::MainFrame::~MainFrame): * page/MainFrame.h: * page/mac/EventHandlerMac.mm: (WebCore::scrollableAreaForContainerNode): (WebCore::latchedToFrameOrBody): (WebCore::areWheelEventsTransitioningToMomentumScrolling): (WebCore::areWheelEventsEndingNonMomentumScrolling): (WebCore::EventHandler::doOrScheduleClearLatchedStateIfNeeded): LayoutTests: * tiled-drawing/scrolling/resources/selects-iframe.html: Added. * tiled-drawing/scrolling/scroll-iframe-latched-selects.html: Added. Canonical link: https://commits.webkit.org/174106@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@198805 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2016-03-29 22:17:04 +00:00
Tests that latched state logic does not get stuck scrolling a specific <select>. To manually run this test, place the mouse pointer
within one left <select> boundary, and then use the mouse wheel or a two-finger to scroll down the list, without momentum scrolling.
Do the same for the right <select>. The left <select> should not scroll when trying to scroll the right <select>.
On success, you will see a series of "PASS" messages, followed by "TEST COMPLETE".
PASS Leftmost <select> was scrolled
PASS Leftmost <select> was not scrolled by the latch state logic
PASS Rightmost <select> was properly scrolled.
PASS successfullyParsed is true
TEST COMPLETE