Bug 1650644 Comment 18 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 #15)
> This is indeed an edge case.
> 
> This test case has a green 100vh height element.  That means  the bottom part of the element is covered by the bottom dynamic toolbar initially.  But the content is not scrollable at all.
> 
> I think APZ needs to tell GeckoView (and GeckoView tells to android-components) that "the input wasn't handled in APZC but need to move the dynamic toolbar".
> 
> To do that, FrameMetrics needs to have a new parameter to represent this situation.

What we have done in the previous dynamic toolbar implementation, is made the toolbar static for pages where the content height is in this range. So, the toolbar would never move, and accordingly APZ uses the smaller height (excluding the toolbar height) to determine whether the page should be vertically scrollable (and the answer is now "yes").
(In reply to Hiroyuki Ikezoe (:hiro) from comment #15)
> This is indeed an edge case.
> 
> This test case has a green 100vh height element.  That means  the bottom part of the element is covered by the bottom dynamic toolbar initially.  But the content is not scrollable at all.
> 
> I think APZ needs to tell GeckoView (and GeckoView tells to android-components) that "the input wasn't handled in APZC but need to move the dynamic toolbar".
> 
> To do that, FrameMetrics needs to have a new parameter to represent this situation.

What we have done in Fennec's dynamic toolbar implementation, is made the toolbar static for pages where the content height is in this range. So, the toolbar would never move, and accordingly APZ uses the smaller height (excluding the toolbar height) to determine whether the page should be vertically scrollable (and the answer is now "yes").

Back to Bug 1650644 Comment 18