WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
196612
[iOS Sim] Layout Test scrollingcoordinator/ios/ui-scroll-fixed.html is a flaky failure
https://bugs.webkit.org/show_bug.cgi?id=196612
Summary
[iOS Sim] Layout Test scrollingcoordinator/ios/ui-scroll-fixed.html is a flak...
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
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1
2019-04-04 10:44:17 PDT
<
rdar://problem/49612867
>
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
Created
attachment 381146
[details]
Patch
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.
Top of Page
Format For Printing
XML
Clone This Bug