The reason why the global ScrollGeneration::sCounter doesn't work for the APZ
case is the APZ sampler thread is per our top level browser window, so if
there are multiple browser windows at the same time, the sCounter will be muted
from different sampler threads.
Differential Revision: https://phabricator.services.mozilla.com/D133439
Both ScrollToCSSPixels and ScrollByCSSPixels are called only from JS via
Element.scrollTo, Element.scrollTop, Element.scrollLeft, Window.scroll,
Window.scrollTo and Window.scrollBy.
Note that we don't target either Window.scrollByLines or Window.scrollByPages
(both end up calling ScrollFrameHelper::ScrollBy) because both are triggered by
user interactions for our XUL tree implementation, for example
Window.scrollByLines gets called in response to a DOMMouseScroll event in
tree.js [1].
[1] https://searchfox.org/mozilla-central/rev/a12c2c2e59c92d8f969d8f3f290ab16919449c9d/toolkit/content/widgets/tree.js#788
Differential Revision: https://phabricator.services.mozilla.com/D130418
Instead of the scrollframe manually calling ScrollGeneration::New this has the
ScrollPositionUpdate do it automatically. Just makes things a little more
encapsulated.
Note that this patch does contain a small functional change, which is that if
ScrollFrameHelper::ScrollToImpl is called with ScrollOrigin::apz, it will not
increment mScrollGeneration whereas it used to before. As far as I can tell
this should be a harmless change.
Depends on D97036
Differential Revision: https://phabricator.services.mozilla.com/D97037
Note in particular the struct keeps its own static (per-process) counter value,
and uses a uint64_t.
Depends on D97034
Differential Revision: https://phabricator.services.mozilla.com/D97035
In some cases (in this scenario, with a RTL XUL scrollframe), the scrollframe
can have a nonzero scroll position upon construction or reconstruction, without
having executed the scrolling code in ScrollFrameHelper::RestoreState or
ScrollFrameHelper::ScrollToRestoredPosition. In such cases APZ is not properly
notified of the scroll position, and it can get into a state where it is out of
sync with the main thread scroll position (until a subsequent scroll).
To correct this, we replace the ScrollPositionUpdate that is created during
scrollframe construction with a new ScrollPositionUpdate that holds the correct
scroll position, so that APZ is properly notified of the scroll position.
Differential Revision: https://phabricator.services.mozilla.com/D90674
This adds a ScrollPositionUpdate class. Code in nsGfxScrollFrame creates
instances of these classes every time the scroll generation is incremented,
and saves them to an array. The array is sent in the scroll metadata to the
compositor as part of a paint transaction.
Currently this data is not used at all on the APZ side, and exists alongside
(independently of) the existing scroll fields, so this patch should not have
any functional effects.
Differential Revision: https://phabricator.services.mozilla.com/D88741
Hiroyuki Ikezoe