In situations where the layout viewport is smaller than the visual viewport, the fixed position element is being sized according to the layout viewport and therefore the fixed position element does not fill the entire visual viewport. In such situations, we would like to size fixed position elements according to the visual viewport instead of the layout viewport. We would also like to contain the layout viewport inside the visual viewport in such situations.

Linking to a testcase that demonstrates the issue. There is some ongoing discussion about it here [1]. We'd like to understand Safari's behaviour on this testcase better before deciding on ours. [1] https://github.com/bokand/bokand.github.io/issues/5

(In reply to Botond Ballo [:botond] from comment #1) > Linking to a testcase that demonstrates the issue. > > There is some ongoing discussion about it here [1]. We'd like to understand > Safari's behaviour on this testcase better before deciding on ours. > > [1] https://github.com/bokand/bokand.github.io/issues/5 The discussion has now concluded. It looks like Safari's behaviour is to attach fixed elements to whichever of the ICB or the visual viewport is larger at the current zoom level. I like this model from a UX point of view. I'm not sure how involved it is to implement, but we'll investigate that. After discussion with Kashav and Tanushree, we are going to proceed in two phases: (1) Async-scroll the layout viewport even if it's smaller than the visual viewport. We'll repurpose this bug for that. Not doing this has caused some noticeable regressions from bug 1465616 that we'd like to fix before re-landing that bug. (2) Try attaching fixed elements to the larger of the ICB and the visual viewport like Safari. We'll do this in a follow-up.

(In reply to Botond Ballo [:botond] from comment #2) > (In reply to Botond Ballo [:botond] from comment #1) > > Linking to a testcase that demonstrates the issue. > > > > There is some ongoing discussion about it here [1]. We'd like to understand > > Safari's behaviour on this testcase better before deciding on ours. > > > > [1] https://github.com/bokand/bokand.github.io/issues/5 > > The discussion has now concluded. It looks like Safari's behaviour is to > attach fixed elements to whichever of the ICB or the visual viewport is > larger at the current zoom level. > > I like this model from a UX point of view. I'm not sure how involved it is > to implement, but we'll investigate that. > > After discussion with Kashav and Tanushree, we are going to proceed in two > phases: > > (1) Async-scroll the layout viewport even if it's smaller than > the visual viewport. We'll repurpose this bug for that. > > Not doing this has caused some noticeable regressions from > bug 1465616 that we'd like to fix before re-landing that bug. > > (2) Try attaching fixed elements to the larger of the ICB and > the visual viewport like Safari. We'll do this in a follow-up. I have posted a review for (1). For (2), I will be attaching a patch which sizes fixed position elements based on the larger of the visual viewport and the layout viewport. However, it positions fixed position elements based on the layout viewport. The next step for this bug will be to position fixed position elements according to the larger of the layout viewport and visual viewport.

(In reply to Tanushree Podder [:tanushree] from comment #4) > For (2), I will be attaching a patch which sizes fixed position elements > based on the larger of the visual viewport and the layout viewport. However, > it positions fixed position elements based on the layout viewport. The next > step for this bug will be to position fixed position elements according to > the larger of the layout viewport and visual viewport. Since (1) is blocking the re-landing of bug 1465616 and (2) is not, we're going to land them in different bugs: this bug for (1), and bug 1477403 for (2). Could you please move the patch for (2) to bug 1477403? Thanks!

Comment on attachment 8994043 [details] Bug 1473699 - Async-scroll the layout viewport even if it's smaller than the visual viewport. https://reviewboard.mozilla.org/r/258624/#review265740 Thanks! Looks pretty good, just a few comments that should be adjusted. ::: gfx/layers/FrameMetrics.cpp:45 (Diff revision 1) > - !FuzzyEqualsMultiplicative(mViewport.Width(), visualViewport.Width())) || > + !FuzzyEqualsMultiplicative(mViewport.Width(), visualViewport.Width())) || > - (mViewport.Height() < visualViewport.Height() && > + (mViewport.Height() < visualViewport.Height() && > - !FuzzyEqualsMultiplicative(mViewport.Height(), visualViewport.Height()))) { > + !FuzzyEqualsMultiplicative(mViewport.Height(), visualViewport.Height()))) { > - return; > + > + if (mViewport.X() < visualViewport.X()) { > + // visual viewport moves right It's still the layout viewport moving, not the visual viewport

Comment on attachment 8994043 [details] Bug 1473699 - Async-scroll the layout viewport even if it's smaller than the visual viewport. https://reviewboard.mozilla.org/r/258624/#review265814

Comment on attachment 8994043 [details] Bug 1473699 - Async-scroll the layout viewport even if it's smaller than the visual viewport. https://reviewboard.mozilla.org/r/258624/#review265914 ::: commit-message-6fb4a:1 (Diff revision 2) > +Bug 1473699 - Part 1: Async-scroll the layout viewport even if it's smaller than the visual viewport. r?botond Please remove the "Part 1" from the commit message, as this is the only patch landing in this bug.

Pushed by bballo@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/75ea630ca0a2 Async-scroll the layout viewport even if it's smaller than the visual viewport. r=botond