1841721 - Make /css/css-scroll-snap/input/keyboard.html less flaky

Status: RESOLVED FIXED

(Core :: Layout: Scrolling and Overflow, task, P3)

Description

[Hiroyuki Ikezoe (:hiro)]

Each test cases in keyboard.html involves async scrolling, and to make sure the async scrolling ends each test ends up using this waitForScrololTo function which checks the current scroll position is the expected one in every scroll event and if it's the expected one, the returned Promise is resolved. Thus if one of the tests fails the check, the tests times out, then any subsequent tests will never be run.

Also, the check is not actually the end of the async scrolling, if an intermediate scroll position is the expected one, the check gets passed.

Anyways, I am going to rewrite it in a more reasonable/less flaky way without using scrollend event. Once after Safari implemented scrollend event we should rewrite the function with using scrollend event.

Comment 1

[Hiroyuki Ikezoe (:hiro)]

Attachment: Bug 1841721 - Rewrite waitForScrollEnd to be less flaky. r?botond

Now it basically does wait for a state where there are 15 consecutive frames
without any scroll events on the given target.

Comment 2

[Hiroyuki Ikezoe (:hiro)]

With D182753 there are still two test failures. One is this test case. The other is this.

I am almost 100% sure the former case is invalid. The test expects that a valid snap position on an intended direction scroll operation should be chosen prior to valid snap position on a snap area covering over the snapport. As far as I can tell the spec doesn't define the behavior. Moreover in the description for scroll-stop property;

When scrolling with an intended direction, the scroll container can “pass over” several possible snap positions (that would be valid to snap to, if the scrolling operation used the same direction but a lesser distance)

So UAs can choose any valid snap position on the snap are covering the snapport rather than a valid snap point on a lesser distance.

The latter case expects that an intended direction scroll operation with proximity can scroll to a position where there's no valid snap point. This looks to me it depends on the threshold of the proximity and the scroll distance of each key press. It may be fixed by bug 1766386?

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/fdcac5f186cb
Rewrite waitForScrollEnd to be less flaky. r=botond

Comment 4

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/40896 for changes under testing/web-platform/tests

Comment 5

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/fdcac5f186cb

Comment 6

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot