Open Bug 1893225 Opened 5 months ago Updated 7 days ago

The dynamic toolbar causes twitchy / jumpy scrolling (with toolbar-on-top)

Categories

(Core :: Panning and Zooming, defect, P3)

defect

Tracking

()

People

(Reporter: mstange, Unassigned)

References

(Depends on 1 open bug, Blocks 3 open bugs)

Details

Attachments

(1 file)

Steps to reproduce:

  1. In Firefox for Android, enable the dynamic toolbar and put it at the top.
  2. On a simple page like https://www.mozilla.org/en-US/ , slowly scroll the page down, hiding the dynamic toolbar.

Expected results:
Scrolling should feel normal.

Actual results:
Scrolling is really jumpy, jerking up and down during the smooth pan.

This is in addition to the twitchy scrolling from bug 1893042.

Attached video screen recording
Blocks: perf-android
Blocks: 1895538

The severity field is not set for this bug.
:botond, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(botond)
Severity: -- → S3
Flags: needinfo?(botond)
Priority: -- → P3
See Also: → 1900161
Duplicate of this bug: 1900161
See Also: 1900161
Blocks: 1894804
No longer blocks: perf-android

So what's going on there roughly is;

  1. the root content APZC starts scrolling
  2. Fenix moves the toolbar in response to the scrolling
  3. the moved distance affects mLocalScreenPoint
  4. Thus touchPoint in TrackTouch is back and forth repeatedly

Though the back and forth touchPoint looks odd, I guess it's kinda expected. Because of the back and forth value the scroll position looks staying at the top, zero position while the toolbar is moving, but actually it's slightly scrolling.

I don't have any great idea to solve this bug other than re-architect the dynamic toolbar stuff. Something like;

  1. Fenix propagates the toolbar state to APZ, i.e. dynamic or static, the toolbar height
  2. when the root content APZC tries to scroll, if the toolbar is dynamic, propagate the scroll distance to Fenix rather than scrolling the content

In 2) we, of course, need to consider if the scroll distance is greater than the current toolbar height, the APZC should scroll the content with the delta.

See Also: → 1515774
Whiteboard: [apz-needsdiscussion]

Yes, I think some re-architecture of the dynamic toolbar, at least in toolbar-on-top mode, is in order.

I think we should do something like this:

  1. Fenix stops setting yTranslation on the Gecko view when it shows the top toolbar. Instead, the Gecko view always stays in the same place, and the toolbar overlaps the content if it's visible.
  2. Fenix informs Gecko about the amount of top overlap. It already has a way to inform it about the amount of bottom overlap. APZ should move fixed-to-top elements down by the amount of top overlap.
  3. APZ scrolls normally. In addition, APZ allows scrolling far enough to the top so that the top of the page can always be reached even while the top toolbar is visible.

(In reply to Markus Stange [:mstange] from comment #5)

  1. Fenix stops setting yTranslation on the Gecko view when it shows the top toolbar. Instead, the Gecko view always stays in the same place, and the toolbar overlaps the content if it's visible.
  2. Fenix informs Gecko about the amount of top overlap. It already has a way to inform it about the amount of bottom overlap. APZ should move fixed-to-top elements down by the amount of top overlap.
  3. APZ scrolls normally. In addition, APZ allows scrolling far enough to the top so that the top of the page can always be reached even while the top toolbar is visible.

A couple of questions:

  1. What should window.scrollY return when the top toolbar is visible and the scroll offset at the GeckoView origin (at the top edge of the toolbar) is y=0 while the scroll offset at the bottom edge of the toolbar is y=TOOLBAR_HEIGHT?
  2. What should window.scrollY return when the top toolbar is visible and the user has used the ability described in point (3) above, to align the y=0 position with the bottom edge of the toolbar?

(In reply to Botond Ballo [:botond] from comment #6)

  1. What should window.scrollY return when the top toolbar is visible and the scroll offset at the GeckoView origin (at the top edge of the toolbar) is y=0 while the scroll offset at the bottom edge of the toolbar is y=TOOLBAR_HEIGHT?

I would expect it to be TOOLBAR_HEIGHT, because that's the amount of page that is hidden.

  1. What should window.scrollY return when the top toolbar is visible and the user has used the ability described in point (3) above, to align the y=0 position with the bottom edge of the toolbar?

At that point it would be zero.

But more generally, my answer is "as close to what happens in Chrome + Safari as possible", which I want to do more research on.

For tracking purposes, this was moved to https://mozilla-hub.atlassian.net/browse/FFXP-2997 due to the dependency we discovered on a larger refactor of how the dynamic toolbar works (as discussed in comment 5).

Whiteboard: [apz-needsdiscussion]
Depends on: 1921331
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: