Smooth scroll animations are reset when scrollTop is changed
Categories
(Core :: Panning and Zooming, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox96 | --- | fixed |
People
(Reporter: mstange, Assigned: hiro)
References
Details
Attachments
(9 files, 1 obsolete file)
|
60.70 KB,
image/png
|
Details | |
|
79.86 KB,
image/png
|
Details | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review |
When scrollTop is set, smooth scroll animations are interrupted. This disturbs the user experience on pages that lazily load content and adjust the scroll position in response, like Slack. In fact, Slack is giving Firefox a slow path due to this bug. See bug 1692705 for more details.
Steps to reproduce:
- Load attachment 9203072 [details].
- Switch to the
setting document.scrollingElement.scrollTopoption with the radio button. - Using the pageup/pagedown keys, or using an external mouse with discrete mousewheel "notches", scroll up and down.
Expected results:
The smooth scroll animation should complete undisturbed.
Actual results:
The smooth scroll animation is interrupted. In addition, the page is reset to an earlier scroll position, discarding the async scroll offset from the smooth scroll. The latter is bug 1692705, the former is this bug.
| Reporter | ||
Comment 1•4 years ago
|
||
I think this aspect is a behavior we've had for a long time, and is not new with APZ.
Comment 2•4 years ago
|
||
Thanks for the reports (bug 1692705, bug 1692707, and this one), Markus!
I've marked them as P3 for now, but given the impact on Slack, I'm going to push to prioritize these (likely shortly after Proton).
| Assignee | ||
Comment 4•4 years ago
|
||
| Assignee | ||
Comment 5•4 years ago
|
||
| Assignee | ||
Comment 6•4 years ago
|
||
This is the way what other similar tests do (e.g.
helper_zoomToFocusedInput_multiline.html [1] and
helper_zoomToFocusedInput_scroll.html [2]).
[1] https://searchfox.org/mozilla-central/rev/126f016b59513988fae56c2b3f69c1cd23fe6ca1/gfx/layers/apz/test/mochitest/helper_zoomToFocusedInput_multiline.html#35-36
[2] https://searchfox.org/mozilla-central/rev/126f016b59513988fae56c2b3f69c1cd23fe6ca1/gfx/layers/apz/test/mochitest/helper_zoomToFocusedInput_scroll.html#33-34
| Assignee | ||
Comment 7•4 years ago
|
||
Without specifying the value, even if synthesizeNativeWheel causes wheel inputs,
it will be converted to an instant scroll rather than smooth. In fact on Mac
mouse wheeling causes this type of events that is that the events'
hasPreciseScrollingDeltas flag is false.
Depends on D129590
| Assignee | ||
Comment 8•4 years ago
|
||
Depends on D129591
| Assignee | ||
Comment 9•4 years ago
|
||
synthesizeKey() just invokes a corresponding command. In "KEY_ArrowDown" case
it's nsISelectionController::ScrollLine [1] which is actually
PresShell::ScrollLine which calls nsIScrollable::ScrollBy, that's not what we
wanted to test for bug 1692707. To exercise APZ's keyboard scrolling we need to
use synthesizeNativeKey instead.
Depends on D129592
| Assignee | ||
Comment 10•4 years ago
|
||
Some mochitests for this change is in the next commit.
Depends on D129593
| Assignee | ||
Comment 11•4 years ago
|
||
Depends on D129594
Updated•4 years ago
|
| Assignee | ||
Updated•4 years ago
|
| Assignee | ||
Comment 12•4 years ago
|
||
This test has a pattern something like;
- Call synthesizeKey to scroll an element
- Wait a scroll event
- Test something
- (Re)set the scroll position to (0, 0) by calling Element.scrollTop and
Element.scrollLeft
With the new transmogrification the step 4) will not reset the scroll position
if there's an on-going scroll animation in APZ triggered by the synthesizeKey.
To avoid the situation where there's an on-going animation, we simply set the
minimum possible smooth scroll animation parameters to minimize the animation
duration thus the animation will immediately end in the first sampling, so at
the step 2) the test can ensure there's no animation.
Depends on D129593
| Assignee | ||
Comment 13•4 years ago
|
||
This test has the same pattern as window_bug1369072.html does.
Call synthesizeKey, wait a scroll event, test something and reset the scrolled
position by calling scrollTo.
We'd set the same preference values in the previous commit.
Depends on D130852
Updated•4 years ago
|
Updated•4 years ago
|
| Assignee | ||
Comment 14•4 years ago
|
||
I did disable helper_relative_scroll_smoothness.html with native-key on Mac's on chaos mode runs (e.g. TV runs) since it fairly fails.
For the record, the failure happens because there appear flat scroll position changes which should have been fixed in bug 1692707. A failure log is;
scroll offset should be strictly monotonically increasing previous offset: 0.01666259765625, offset: 0.01666259765625
I am assuming on chaos mode we somehow sample same scroll position because we miss keyboard input event handling or some such on heavy load state.
Comment 15•4 years ago
|
||
Comment 16•4 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/5d8fb911d61e
https://hg.mozilla.org/mozilla-central/rev/9256faddf559
https://hg.mozilla.org/mozilla-central/rev/d4b0e298abed
https://hg.mozilla.org/mozilla-central/rev/8beac9395793
https://hg.mozilla.org/mozilla-central/rev/b31c1668258d
https://hg.mozilla.org/mozilla-central/rev/f26b5d17b34b
https://hg.mozilla.org/mozilla-central/rev/361c96f8f312
Updated•4 years ago
|
Description
•