flickering smooth-scroll animation when pointer-events is set to none and GPU layer is used
Categories
(Core :: Graphics, defect, P3)
Tracking
()
People
(Reporter: axyzxp, Unassigned)
References
Details
(Keywords: regression)
Attachments
(2 files)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:70.0) Gecko/20100101 Firefox/70.0
Steps to reproduce:
This is a way to implement a carousel with native interactions as well as JS triggers.
This codepen reproduce the issue on Firefox 70.0.1
https://codepen.io/axyz/pen/JjoYPgd?editors=1111
clicking prev or next, will trigger a native scroll animated using smooth-scroll.
The animation will flicker and leave part of the overflowed hidden layer leaking on top.
The behavior is quite consistent, but the artifacts may disappear after few seconds or after some interactions.
The problem does not happen when the inspector is open. Even if the inspector is open and then closed again, the problem does not happen, but refreshing the page will make it happen again.
Actual results:
When smooth scroll animation is triggered by setting scroll values using JavaScript and the scrolling container has pointer-events set to none and is put in the GPU layer using transform, will-change or similar techniques the end of the animation results in artifacts on the overflowed edges.
Removing the pointer-events, removing the will-change, or removing the smooth-scroll all result in fixing the problem.
Expected results:
no flickering should happen on the edges and the overflowed part should remain hidden
Comment 1•4 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
Comment 2•4 years ago
|
||
I can reproduce this, only when WebRender is disabled.
The behavior changed from 63 to 64 because we shipped scrollbar-width: none
.
I don't know what makes opening devtools not reproduce the problem... Does devtools change something with our APZ setup?
Comment 3•4 years ago
|
||
Oh, also the bug seems to repro with overflow: hidden instead of scrollbar-width: none
, so that probably can give a more accurate regression range.
Comment 4•4 years ago
|
||
Comment 5•4 years ago
|
||
I lie, overflow: hidden
instead of overflow-x: scroll; scrollbar-width: none
does work...
That probably works as a workaround, that's something.
Here's the original test-case though.
Updated•4 years ago
|
(In reply to Emilio Cobos Álvarez (:emilio) from comment #5)
Created attachment 9114505 [details]
Test-case from reporterI lie,
overflow: hidden
instead ofoverflow-x: scroll; scrollbar-width: none
does work...That probably works as a workaround, that's something.
Here's the original test-case though.
overflow: hidden
will prevent the scroll though when pointer-events is not set.
To better explain the use case: normally the scroller does not have pointer-events: none
so that normal touch and double finger scroll will work and there is no graphic issue in that situation. When the scroll is triggered using javascript, we add pointer-events: none
in order to prevent a touch action to interrupt the animation and mess up the slider current index. Enabling pointer-events bring us to the setup shown on the codepen and the flickering issue.
Comment 8•4 years ago
|
||
Err sorry, saved comment :)
Comment 9•4 years ago
•
|
||
For the scrollbar-width: none
testcase, the regression range is
6:03.31 INFO: Last good revision: 2e3e89c9c68cd6b09d1853dc5426df3c04971c29 (2018-09-25)
6:03.31 INFO: First bad revision: 7ac88abc3c57832e7e271dede934f8935c7f83a0 (2018-09-26)
6:03.31 INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2e3e89c9c68cd6b09d1853dc5426df3c04971c29&tochange=7ac88abc3c57832e7e271dede934f8935c7f83a0
which includes bug 1492012.
I was not able to reproduce the bug with the second testcase.
Updated•3 years ago
|
Updated•1 year ago
|
Description
•