I can sort of see how bug 1549625 might cause this: * The top bar disppearing causes the scroll port to expand while the content size remains the same. This results in the (layout) scroll range shrinking. * We re-clamp the scroll position to the new layout scroll range, and due to bug 1549625 suppress the resulting main-thread scroll offset update, leaving us at the out-of-bounds offset visually. However, we should still be sending a transaction with the new scroll port (composition bounds), which should cause APZ to re-clamp the scroll offset visually as well. I'd like to understand why this is not happening, before considering a change to the bug 1549625 mechanism. Unfortunately, despite a multitude of attempts in various configurations, I have not been able to reproduce this on either Linux or Android. It's possible it only reproduces on Mac (if so, it would be interesting to understand why that is, too).
Bug 1551582 Comment 2 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
I can sort of see how bug 1549625 might cause this: * The top bar disppearing causes the scroll port to expand while the content size remains the same. This results in the (layout) scroll range shrinking. * We re-clamp the scroll position to the new layout scroll range, and due to bug 1549625 suppress the resulting main-thread scroll offset update, leaving us at the out-of-bounds offset visually. However, we should still be sending a transaction with the new scroll port (composition bounds), which should cause APZ to re-clamp the scroll offset visually as well. I'd like to understand why this is not happening, before considering a change to the bug 1549625 mechanism. Unfortunately, despite a multitude of attempts in various configurations, I have not been able to reproduce this on either Linux, Windows, or Android. It's possible it only reproduces on Mac (if so, it would be interesting to understand why that is, too).