Bug 196612

Summary: [iOS Sim] Layout Test scrollingcoordinator/ios/ui-scroll-fixed.html is a flaky failure
Product: WebKit Reporter: Shawn Roberts <sroberts>
Component: Tools / TestsAssignee: Simon Fraser (smfr) <simon.fraser>
Status: RESOLVED FIXED    
Severity: Normal CC: commit-queue, fred.wang, koivisto, lforschler, sam, simon.fraser, webkit-bot-watchers-bugzilla, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
See Also: https://bugs.webkit.org/show_bug.cgi?id=195521
Attachments:
Description Flags
Patch none

Shawn Roberts
Reported 2019-04-04 10:43:24 PDT
The following layout test is flaky on iOS Simulator Release WK2 scrollingcoordinator/ios/ui-scroll-fixed.html Probable cause: Test was added in https://trac.webkit.org/changeset/242683/webkit A note was made on previous bug, but a fix does not appear to have been made. Flakiness Dashboard: https://webkit-test-results.webkit.org/dashboards/flakiness_dashboard.html#showAllRuns=true&tests=scrollingcoordinator%2Fios%2Fui-scroll-fixed.html Diff: https://build.webkit.org/results/Apple%20iOS%2012%20Simulator%20Release%20WK2%20(Tests)/r243869%20(3458)/scrollingcoordinator/ios/ui-scroll-fixed-diff.png
Attachments
Patch (3.95 KB, patch)
2019-10-16 18:50 PDT, Simon Fraser (smfr)
no flags
Radar WebKit Bug Importer
Comment 1 2019-04-04 10:44:17 PDT
Shawn Roberts
Comment 2 2019-04-04 10:50:25 PDT
Marked flaky in https://trac.webkit.org/changeset/243881/webkit while waiting for a fix
Simon Fraser (smfr)
Comment 3 2019-10-16 14:23:23 PDT
I can reproduce. This only seems to happen if amount scrolled (50px) is identical to the top of #container, so we must have an early return in code somewhere.
Simon Fraser (smfr)
Comment 4 2019-10-16 18:50:53 PDT
Antti Koivisto
Comment 5 2019-10-16 22:54:32 PDT
Comment on attachment 381146 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=381146&action=review > LayoutTests/ChangeLog:14 > + This test hit a really obscure bug where a combination of an immediate scroll, and > + an ancestor reposition left the layer position of a position:fixed layer unchanged. > + The position of this layer in the UI process had been previously modified by > + the scrolling tree for the scroll, but because the WebContent-side mutations left > + the actual position unchanged, we'd never apply a new position via a commit, so left > + the layer in the wrong location. Would this be fixed by a web->ui message that that signals we did a compositing layer update but nothing changed, so we are skipping the commit? This would just call applyLayerPositionsAfterCommit() to check for m_wasScrolledByDelegatedScrollingSincePreviousCommit bit. > LayoutTests/ChangeLog:19 > + Since this is so hard to hit with noisy user scrolling, just change the test to avoid > + the perfect storm of scrolls and offsets. Since we have managed to make a test for this it bit sad to let it go waste.
Simon Fraser (smfr)
Comment 6 2019-10-17 10:51:47 PDT
I filed bug 203112 to cover the underlying bug.
WebKit Commit Bot
Comment 7 2019-10-17 12:05:33 PDT
The commit-queue encountered the following flaky tests while processing attachment 381146 [details]: imported/w3c/web-platform-tests/mathml/presentation-markup/operators/mo-form-fallback.html bug 203076 (authors: fred.wang@free.fr and rwlbuis@gmail.com) imported/w3c/web-platform-tests/websockets/bufferedAmount-unchanged-by-sync-xhr.any.worker.html bug 202003 (author: youennf@gmail.com) The commit-queue is continuing to process your patch.
WebKit Commit Bot
Comment 8 2019-10-17 12:06:29 PDT
Comment on attachment 381146 [details] Patch Clearing flags on attachment: 381146 Committed r251251: <https://trac.webkit.org/changeset/251251>
WebKit Commit Bot
Comment 9 2019-10-17 12:06:31 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.