haikuwebkit/LayoutTests/fast/events/scroll-subframe-in-renderin...

17 lines
553 B
Plaintext
Raw Permalink Normal View History

Integrate scroll event into HTML5 event loop https://bugs.webkit.org/show_bug.cgi?id=203839 <rdar://problem/56890922> Reviewed by Simon Fraser. Source/WebCore: Dispatch scroll events on each pending scroll event targets inside the update-the-rendering step of the event loop as specified in the HTML5 and CSSOM View Module specifications: https://html.spec.whatwg.org/multipage/webappapis.html#update-the-rendering https://drafts.csswg.org/cssom-view/#run-the-scroll-steps The new behavior also matches that of Chrome and Firefox. Like resize event, the current visual viewport specification does not specify when scroll event is dispatched on visualViewport interface: https://github.com/WICG/visual-viewport/issues/66 For now, we always dispatch upon it after dispatching on all pending scroll event targets. Tests: fast/events/scroll-multiple-elements-in-rendering-update.html fast/events/scroll-subframe-in-rendering-update.html fast/visual-viewport/visual-viewport-scroll-after-resize-in-subframe.html * dom/Document.cpp: (WebCore::Document::addPendingScrollEventTarget): Added. (WebCore::Document::setNeedsVisualViewportScrollEvent): Added. (WebCore::Document::runScrollSteps): Added. This implements run the scroll steps in CSS OM View. * dom/Document.h: * dom/DocumentEventQueue.cpp: (WebCore::DocumentEventQueue::enqueueOrDispatchScrollEvent): Deleted. (WebCore::DocumentEventQueue::enqueueScrollEvent): Deleted. * dom/DocumentEventQueue.h: * page/EventHandler.cpp: (WebCore::EventHandler::sendScrollEvent): * page/Page.cpp: (WebCore::Page::updateRendering): Invoke runScrollSteps on each document in the frame tree order. * page/VisualViewport.cpp: (WebCore::VisualViewport::update): (WebCore::VisualViewport::enqueueScrollEvent): Deleted. * page/VisualViewport.h: * rendering/RenderLayer.cpp: (WebCore::RenderLayer::scrollTo): * rendering/RenderListBox.cpp: (WebCore::RenderListBox::scrollTo): LayoutTests: Added tests to test the timing at which scroll events are fired across multiple elements and documents, and with visualViewport, and updated the existing tests to work with the new timing. * editing/selection/overflow-scroll-while-selecting-text.html: * fast/events/scroll-multiple-elements-in-rendering-update-expected.txt: Added. * fast/events/scroll-multiple-elements-in-rendering-update.html: Added. * fast/events/scroll-subframe-in-rendering-update-expected.txt: Added. * fast/events/scroll-subframe-in-rendering-update.html: Added. * fast/scrolling/programmatic-scroll-to-negative-offset.html: * fast/shadow-dom/trusted-event-scoped-flags.html: * fast/visual-viewport/visual-viewport-scroll-after-resize-in-subframe-expected.txt: Added. * fast/visual-viewport/visual-viewport-scroll-after-resize-in-subframe.html: Added. * tiled-drawing/scrolling/fast-scroll-div-latched-mainframe.html: Canonical link: https://commits.webkit.org/217303@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@252205 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2019-11-07 22:18:37 +00:00
This tests that scroll event is dispatched in the update-the-rendering step in the event loop across all relevant frames
On success, you will see a series of "PASS" messages, followed by "TEST COMPLETE".
iframeB.contentWindow.scrollTo(0, 1000); updateLayout(iframeB)
iframeA.contentWindow.scrollTo(0, 1000); updateLayout(iframeA)
iframeAA.contentWindow.scrollTo(0, 1000); updateLayout(iframeAA)
PASS logs.length is 0
After requestAnimationFrame
PASS logs.length is 3
PASS logs.join(", ") is "A, AA, B"
PASS successfullyParsed is true
TEST COMPLETE