Bug 1692707 Comment 3 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

(In reply to Hiroyuki Ikezoe (:hiro) from comment #2)
> I've started looking at this issue.  So far what I've suspected is [GenericScrollAnimation::HandleScrollOffsetUpdate](https://searchfox.org/mozilla-central/rev/01adc17c9a41d9f7975de170acc78634bd743609/gfx/layers/apz/src/GenericScrollAnimation.cpp#113).  This GenericScrollAnimation is being used for keyboard scrolling and this HandleScrollOffsetUpdate is called when we update the relative position change triggered by scrollBy(). 

I was wrong.  HandleScrollOffsetUpdate is not directly related to this issue.  A directly related issue is [this sampledState.UpdateScrollProperties(Metrics())](https://searchfox.org/mozilla-central/rev/0ec81de2037cb0a0701d5d316f42763230b3a142/gfx/layers/apz/src/AsyncPanZoomController.cpp#5230), it gets called in response to each scrollBy call, thus if there are multiple already-sampled scroll offsets, they will be same value at the moment when NotifyLayersUpdated is called.  So in subsequent compositions, we will use the same value as scroll offsetsfor a while.  That's what I've observed so far.  That means scroll offsets are not back to smaller values, it sometimes stay at a position, as far as I can tell at least on Linux.
(In reply to Hiroyuki Ikezoe (:hiro) from comment #2)
> I've started looking at this issue.  So far what I've suspected is [GenericScrollAnimation::HandleScrollOffsetUpdate](https://searchfox.org/mozilla-central/rev/01adc17c9a41d9f7975de170acc78634bd743609/gfx/layers/apz/src/GenericScrollAnimation.cpp#113).  This GenericScrollAnimation is being used for keyboard scrolling and this HandleScrollOffsetUpdate is called when we update the relative position change triggered by scrollBy(). 

I was wrong.  HandleScrollOffsetUpdate is not directly related to this issue.  A directly related issue is [this sampledState.UpdateScrollProperties(Metrics())](https://searchfox.org/mozilla-central/rev/0ec81de2037cb0a0701d5d316f42763230b3a142/gfx/layers/apz/src/AsyncPanZoomController.cpp#5230), it gets called in response to each scrollBy call, thus if there are multiple already-sampled scroll offsets, they will be same value at the moment when NotifyLayersUpdated is called.  So in subsequent compositions, we will use the same value as scroll offsets for a while.  That's what I've observed so far.  That means scroll offsets are not back to smaller values, it sometimes stay at a position, as far as I can tell at least on Linux.
(In reply to Hiroyuki Ikezoe (:hiro) from comment #2)
> I've started looking at this issue.  So far what I've suspected is [GenericScrollAnimation::HandleScrollOffsetUpdate](https://searchfox.org/mozilla-central/rev/01adc17c9a41d9f7975de170acc78634bd743609/gfx/layers/apz/src/GenericScrollAnimation.cpp#113).  This GenericScrollAnimation is being used for keyboard scrolling and this HandleScrollOffsetUpdate is called when we update the relative position change triggered by scrollBy(). 

I was wrong.  HandleScrollOffsetUpdate is not directly related to this issue.  A directly related issue is [this sampledState.UpdateScrollProperties(Metrics())](https://searchfox.org/mozilla-central/rev/0ec81de2037cb0a0701d5d316f42763230b3a142/gfx/layers/apz/src/AsyncPanZoomController.cpp#5230), it gets called in response to each scrollBy call, thus if there are multiple already-sampled scroll offsets, they will be same value at the moment when NotifyLayersUpdated is called.  So in subsequent compositions, we will use the same value as scroll offsets for a while.  That's what I've observed so far.  That means scroll offsets are not back to smaller values, it sometimes stays at a position, as far as I can tell at least on Linux.

Back to Bug 1692707 Comment 3