Issue metadata
Sign in to add a comment
|
threaded smooth scroll layout tests are flaky |
||||||||||||||||||||||||
Issue descriptionMost of the following tests are flaky (failing or timing out) with threaded scrolling: - fast/scroll-behavior/overflow-scroll-animates.html - fast/scroll-behavior/overflow-scroll-root-frame-animates.html - fast/scroll-behavior/smooth-scroll/* - virtual/threaded/fast/scroll-behavior/smooth-scroll/* All of the flaky tests trigger smooth user scrolls with eventSender and wait for the animations to complete. Some of these tests are only meaningful with threaded scrolling, so it would be good to get them working in virtual/threaded. I've had trouble reproducing the issue locally. Debug bots seem to see more flakiness than release bots. In r431145 I tried raising the timeout in shouldBecomeEqual, but that didn't help. Various bugs have been filed against individual tests but it probably makes sense to track the underlying issue in one place.
,
Nov 15 2016
,
Nov 15 2016
Issue 593568 has been merged into this issue.
,
Nov 15 2016
,
Nov 15 2016
Issue 487880 has been merged into this issue.
,
Nov 16 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/03039b7b951dd4d7f48dc6f1eef0786e9d1c4196 commit 03039b7b951dd4d7f48dc6f1eef0786e9d1c4196 Author: skobes <skobes@chromium.org> Date: Wed Nov 16 01:39:34 2016 Organize TestExpectations for smooth scroll flakiness. BUG= 665577 Review-Url: https://codereview.chromium.org/2503683004 Cr-Commit-Position: refs/heads/master@{#432348} [modify] https://crrev.com/03039b7b951dd4d7f48dc6f1eef0786e9d1c4196/third_party/WebKit/LayoutTests/TestExpectations
,
Nov 16 2016
,
Nov 23 2016
,
Dec 1 2016
This appears to be a scheduling issue where we flood the compositor thread task queue with invocations of DisplayScheduler::OnBeginFrameDeadline. This causes the main thread to block for long periods of time waiting for ProxyImpl::NotifyReadyToCommitOnImpl. As a result, we send scroll events at very low (and inconsistent) frequency, even though main is idle and cc is drawing frames relatively quickly.
,
Dec 1 2016
Sounds like this is out of scope for Blink animations.
,
Dec 1 2016
When you say flooding the task queue, do you mean like a task every 16ms (like every vsync..) or do you mean more than that? Do you have a trace or something? The default behaviour will be to generate a frame every 1/60th of a second. It can be changed by switches::kDisableGpuVsync which would make as many frames as possible but I don't see in the code. Or the ui::ContextFactory::DoesCreateTestContexts() returning true which would make a frame every 1/200th of a second instead, but I think layout tests would just use production ie GpuProcessTransportFactory for this which returns false.
,
Dec 1 2016
No, it's every ~200ms because that's how long DrawAndSwap takes. That's not great but maybe expected on a debug build? Anyway if we could get scroll events every 200ms we'd be fine but instead I'm seeing delays of multiple seconds between scroll events. I'm not sure how to take a trace with --run-layout-test, do you know? I've just been using logging and gdb.
,
Dec 1 2016
Actually I take that back... even if we get one scroll event per DrawAndSwap we will not be fine if DrawAndSwap takes longer than the animation duration. We may need a different approach. :-/
,
Dec 1 2016
Ya that's not a good test cuz drawandswap can be arbitrarily slow given a slow enough machine and enough dchecks etc. fwiw we removing some dchecks of sync calls to the gpu recently which would speed up clipping a lot in debug builds but.. the approach is problematic as you say.
,
Dec 1 2016
Most of the slowness of debug build DrawAndSwap is from the call to GetIntegerv in GLRenderer::SetScissorTestRect.
,
Dec 1 2016
Well that's gone (or going away?) on ToT. But points out the inherit design flaw here, which would make them flaky on a loaded machine, instead of fail more consistently due to GL sync calls.
,
Mar 27 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/1c9ca7ff21bc5e845a66bc4f3f36e1f2937cbb6f commit 1c9ca7ff21bc5e845a66bc4f3f36e1f2937cbb6f Author: qyearsley <qyearsley@chromium.org> Date: Mon Mar 27 20:11:58 2017 Remove TestExpectations lines for tests which appear to be non-flaky recently. This change was made by the update-test-expectations script. Recent test results history: https://test-results.appspot.com/dashboards/flakiness_dashboard.html#testType=webkit_tests&tests=fast/css/text-overflow-ellipsis-button.html,virtual/threaded/fast/scroll-behavior/smooth-scroll/ongoing-smooth-scroll-vertical-rl-anchors.html,virtual/mojo-loading/http/tests/security/contentSecurityPolicy/require-sri-for/require-sri-for-script-reportonly-blocked.php,external/wpt/service-workers/service-worker/fetch-request-redirect.https.html,external/wpt/preload/preload-with-type.html,fast/table/border-collapsing/001-vertical.html,fast/table/border-collapsing/001.html BUG= 659123 , 665577 ,664816, 688486 , 698521 , 701718 Review-Url: https://codereview.chromium.org/2778843002 Cr-Commit-Position: refs/heads/master@{#459865} [modify] https://crrev.com/1c9ca7ff21bc5e845a66bc4f3f36e1f2937cbb6f/third_party/WebKit/LayoutTests/TestExpectations
,
Oct 24 2017
Perhaps this is a related timeout, should it be marked flaky and cite this bug? https://uberchromegw.corp.google.com/i/chromium.linux/builders/Linux%20Tests/builds/63728 * virtual/threaded/fast/scroll-behavior/smooth-scroll/mousewheel-scroll-interrupted.html 07:29:16.674 6611 killed pid 17225 07:29:48.088 6611 killed pid 17579 07:29:48.090 6611 worker/4 virtual/threaded/fast/scroll-behavior/smooth-scroll/mousewheel-scroll-interrupted.html output stderr lines: 07:29:48.090 6611 07:29:48.090 6611 DevTools listening on ws://127.0.0.1:59278/devtools/browser/6f3b721d-9f95-4143-b850-40ad22d526a0 07:29:48.090 6611 Xlib: extension "RANDR" missing on display ":100". 07:29:48.091 6466 [2933/10642] virtual/threaded/fast/scroll-behavior/smooth-scroll/mousewheel-scroll-interrupted.html failed unexpectedly (test timed out) 07:29:48.090 6611 worker/4 killing primary driver 07:29:48.093 6611 worker/4 killing secondary driver 07:29:48.093 6611 worker/4 virtual/threaded/fast/scroll-behavior/smooth-scroll/mousewheel-scroll-interrupted.html failed: 07:29:48.093 6611 worker/4 test timed out Other webkit_layout_tests timed out similarly in recent runs, so I'm not sure what's related.
,
Nov 23 2017
,
Dec 13 2017
,
Jan 3 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/9cb52eca7bbf5d6314c80eeae11c4b254cd4ce13 commit 9cb52eca7bbf5d6314c80eeae11c4b254cd4ce13 Author: Xida Chen <xidachen@chromium.org> Date: Wed Jan 03 19:33:05 2018 Mark mousewheel-scroll-interrupted.html as Timeout on Linux This instance shows that the virtual/threaded/fast/scroll-behavior/smooth-scroll/mousewheel-scroll-interrupted.html could time out on Linux. TBR=hiroshige@chromium.org NOTRY=true Bug: 665577 Change-Id: I65f1e8f70a180cdcc0f6d8e9263fd4897231bfeb Reviewed-on: https://chromium-review.googlesource.com/848035 Reviewed-by: Xida Chen <xidachen@chromium.org> Commit-Queue: Xida Chen <xidachen@chromium.org> Cr-Commit-Position: refs/heads/master@{#526769} [modify] https://crrev.com/9cb52eca7bbf5d6314c80eeae11c4b254cd4ce13/third_party/WebKit/LayoutTests/TestExpectations
,
Sep 6
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by skobes@chromium.org
, Nov 15 2016