1880375 - footer with "position:fixed;bottom:0" doesn't stay attached to bottom of mobile viewport (and moves further upwards on the screen than expected), when page is pinch-zoomed and dynamic toolbar disappears

Status: RESOLVED FIXED

(Core :: Panning and Zooming, defect, P3)

Description

[Daniel Holbert [:dholbert]]

Attachment: (ignore; broken version of testcase 1)

STR:

1. View attached testcase in Firefox on Android.
2. Pinch-zoom to slightly zoom in (to e.g. a blank area on the page).
3. Scroll downwards on the page. Try scrolling up and down (so the toolbar appears/disappears), and try scrolling to the bottom.

(Be sure you have "scroll to hide toolbar" enabled in your browser settings.)

ACTUAL RESULTS:

• When the browser toolbar disappears, the fixed-position footer (orange-with-lime-border) disconnects from the bottom of the viewport and moves upwards in the page.
• If you scroll all the way to the bottom, the red element is visible.

EXPECTED RESULTS:

• The fixed position footer should not move higher in the viewport than the bottom of the viewport.
• The red area should never be visible. It's the same height as the fixed footer, and it's the last thing in the page; so when you're scrolled to the end, that red area should be entirely covered up by the fixed footer.

Note: I ran into this in-the-wild, at this restaurant menu/about-page:
https://ludwigsmv.com/mountain-view-in-order-to-expedite-service-we-will-accept-three-cards-maximum-per-transaction-ludwigs-biergarten-about

I tested both Firefox Nightly 124 and release 122 on my Pixel 8 (Android 14), and got ACTUAL RESULTS.
Chrome on the same device gives EXPECTED RESULTS.

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

Comment 2

[Daniel Holbert [:dholbert]]

(This might be a dupe; it feels like something we probably would have run into before. I didn't find the same bug when doing a quick search just now, though.)

Comment 3

[Hiroyuki Ikezoe (:hiro)]

I think once after we addressed bug 1641166, this will be also fixed by it. I mean, this is a part of issues where the zoom scale value isn't 1.0.

Comment 4

[Luke]

Here's a testcase I wrote debugging the same problem: https://output.jsbin.com/jakiguw

• Firefox for Android's position: fixed; bottom: 0 behaves similarly to Chrome for Android's position: absolute; top: calc(100dvh - var(--own-height)).
• Conversely, Firefox for Android's position: absolute; top: calc(100dvh - var(--own-height)) behaves similarly to Chrome for Android's position: fixed; bottom: 0.

However, if you lock and unlock the phone after pinch zooming, the two divs switch places to their correct positions ¯\_(ツ)_/¯

Comment 5

[Markus Stange [:mstange]]

This feels pretty broken. I can reproduce it on https://weather.com/ too.

Comment 6

[MGSimard]

Big issue for me on https://vertexblog.vercel.app/

Happens when I pinch zoom - taskbar that is fixed to bottom will unstick and an empty space appears below. I turned on the Mobile DevTools extension to have a look and see if it was a layout problem, and it turns out it's a space created completely outside the DOM hierarchy when hovering over elements. The DevTools window itself also inherits that bottom gap.

Not an issue on any other browser I've tested on for both mobile and desktop.

Comment 7

[Markus Stange [:mstange]]

On the compositor side, we currently adjust the position of fixed elements based on the difference between the "compositor fixed layer margins" and the "gecko fixed layer margins": https://searchfox.org/firefox-main/rev/c2e3c0aea49fb45082efdc129e79f84df7a07f48/gfx/layers/apz/src/APZCTreeManager.cpp#3872

I think this is the right idea, we just need two tweaks:

• make sure the gecko fixed layer margins are accurate, i.e. audit whether the value we set on the gecko side matches the value that was actually used when positioning fixed elements during layout
• scale the adjustment offset by the zoom. If we compute a "screen margin" of 10 screen pixels, and if those translate into 5 CSS pixels at the default scale, they should still translate to 5 CSS pixels at the zoomed scale.

We also need to find out the code that causes the "jump", i.e. which causes any non-default scale to have different behavior than the default scale.

Comment 8

[Alex Jakobi [:ajakobi]]

Attachment: Bug 1880375 - Use fixed viewport accounted for dynmamic toolbar height for fixed position elements r?hiro,botond,mstange

Comment 9

[Alex Jakobi [:ajakobi]]

Attachment: Behavior after fix from D269773

Adding a recording with the behavior after the attempted fix from D269773 was implemented.

Comment 10

[Alex Jakobi [:ajakobi]]

Attachment: Bug 1880375 - Add reftest for position fixed element at bottom while zoomed in r?botond,hiro

Comment 11

[Alex Jakobi [:ajakobi]]

Attachment: Bug 1880375 - Use FixedViewportHeightUpdatedByDynamicToolbar for fixed position elements r?hiro,botond,mstange

Comment 12

[Hiroyuki Ikezoe (:hiro)]

Attachment: A test image on InteractiveWidgetTest#stickyElementWithDynamicToolbarOnResizesVisual

I ran InteractiveWidgetTest#stickyElementWithDynamicToolbarOnResizesVisual locally with .the current D269773. Attaching file is an image of the screenshot of the test image.

As you can see it's totally bogus.

There's a red bar at the bottom of the image, but it should be green.

More interestingly the bar in the reference image is gray. I am going to attach the reference image.

Comment 13

[Hiroyuki Ikezoe (:hiro)]

Attachment: The reference image

Here is the reference image.

Comment 14

[Hiroyuki Ikezoe (:hiro)]

Ooops. when I looked at the reference image on Firefox, there's a gray bar at the bottom, but it seem the area is not gray, it's transparent.

Comment 15

[Alex Jakobi [:ajakobi]]

Attachment: interactive-widget-w-input.html

Comment 16

[Alex Jakobi [:ajakobi]]

Attachment: Screen recording with virtual keyboard

With D269773@1185166, we found the attached issue in conjunction with the virtual keyboard when looking at the attached test page 'interactive-widget-w-input.html' which is interactive-widget.html with an added input field (that allows us to open the virtual keyboard).
We noticed that the position:fixed element doesn't behave correctly, only showing up when moving the page and being misplaced.

Hiro, could this be a bug 'uncovered' by D269773@1185166, or is this defective behavior caused by it? Is there an effect of the virtual keyboard on the fixed viewport size? I notice there vh-units being used in the page, could it be related to bugs around them?

Comment 17

[Hiroyuki Ikezoe (:hiro)]

Just a quick note after watching the recording.

A relevant code is probably here in APZ.

I wonder even there's the keyboard appeared we do need to move the fixed layers?

Comment 18

[Hiroyuki Ikezoe (:hiro)]

(In reply to Alex Jakobi [:ajakobi] from comment #16)

Is there an effect of the virtual keyboard on the fixed viewport size?

So this is a fundamental question. In my naive sense, the fixed viewport should not be affected by the dynamic toolbar movement while the software keyboard is visible with interactive-widget=resizes-visual since the toolbar movement only affects the visual viewport which is independent from the fixed viewport (or I should say the fixed viewport is independent from the visual viewport)

Comment 19

[Hiroyuki Ikezoe (:hiro)]

diff --git a/layout/base/PresShell.cpp b/layout/base/PresShell.cpp
index cdd380713d80..90d3e8fbf9aa 100644
--- a/layout/base/PresShell.cpp
+++ b/layout/base/PresShell.cpp
@@ -12415,6 +12415,10 @@ nsSize PresShell::GetVisualViewportSizeUpdatedByDynamicToolbar() const {
 
 nsSize PresShell::GetFixedViewportSize() const {
   nsSize layoutViewportSize = GetLayoutViewportSize();
+  if (!mPresContext->IsKeyboardHiddenOrResizesContentMode()) {
+    return layoutViewportSize;
+  }
+
   layoutViewportSize.height +=
       mPresContext->GetBimodalDynamicToolbarHeightForFixedPosInAppUnits();
   return layoutViewportSize;

This change should fix the wonky position:fixed movement. But there's a side effect that the white blank area appears where the dynamic toolbar existed when moving the toolbar.

IIRC, Markus suggested a new toolbar model in a certain case something like only scrolling the content not moving the toolbar. I think this is the case, in this specific case we just needs to visually scroll the content without hiding the toolbar.

IIRC, Safari's toolbar looks like this model.

I don't have any clear/good solution to avoid any side-effects. I would say the white blank are less ugly than the wonky position:fixed movement.

Also note that I hope this patch also fixes the InteractiveWidgetTest#stickyElementWithDynamicToolbarOnResizesVisual failure.

Comment 20

[Hiroyuki Ikezoe (:hiro)]

(In reply to Hiroyuki Ikezoe (:hiro) from comment #19)

Also note that I hope this patch also fixes the InteractiveWidgetTest#stickyElementWithDynamicToolbarOnResizesVisual failure.

Confirmed it does fix the failure.

Comment 21

[Hiroyuki Ikezoe (:hiro)]

I pushed a try run with the change in comment 19; https://treeherder.mozilla.org/jobs?repo=try&revision=2a4c8c103db8e519a815d1844d25b0f6a782a09d. The result looks promising.

Comment 22

[Alex Jakobi [:ajakobi]]

Attachment: Bottom gap with toolbar on top, comparing central and patch

I noticed a gap at the bottom between the fixed element and the screen bottom that seems to have the dynamic toolbar height and appears as the top toolbar expands (when zoomed in).
The behavior is not regressed by our patch as of D269773#1185166.
I'm wondering if this should be fixed with this bug or, since we will alter the behavior for the top toolbar scenarios (and with the overlap model) later on anyway, should cover it with the subsequent work?

Comment 23

[Hiroyuki Ikezoe (:hiro)]

Geez. I would say it should be fixed in a separate bug.

In APZ we accept both of top and bottom margins; https://searchfox.org/firefox-main/rev/5ccc7ced6d5cf0068cd65d8da65359dd745411b0/gfx/layers/apz/src/APZCTreeManager.cpp#3861-3862
But in GeckoView as the function name standing for (setFixedBottomOffset), it was designed for position:fixed elements fixed to the bottom of the viewport.

The reason behind this I can think of is the top toolbar doesn't overlay the contents at all.

We will end up introducing a new API accepting ScreenMargin to fix this case.

Comment 24

[Markus Stange [:mstange]]

(In reply to Alex Jakobi [:ajakobi] from comment #22)

I noticed a gap at the bottom between the fixed element and the screen bottom that seems to have the dynamic toolbar height and appears as the top toolbar expands (when zoomed in).
The behavior is not regressed by our patch as of D269773#1185166.
I'm wondering if this should be fixed with this bug or, since we will alter the behavior for the top toolbar scenarios (and with the overlap model) later on anyway, should cover it with the subsequent work?

Interesting! Let's have a follow-up bug for it so that we can land this patch - this patch doesn't make it worse.

Comment 25

[Alex Jakobi [:ajakobi]]

(In reply to Markus Stange [:mstange] from comment #24)

Interesting! Let's have a follow-up bug for it so that we can land this patch - this patch doesn't make it worse.

Follow-up: bug 2012733

Comment 26

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/48db7559259a
https://hg.mozilla.org/integration/autoland/rev/0a7faf975d3f
Use fixed viewport accounted for dynmamic toolbar height for fixed position elements r=hiro,layout-reviewers,geckoview-reviewers

Comment 27

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/64946aa860dd
https://hg.mozilla.org/integration/autoland/rev/d154d7fdf800
Add reftest for position fixed element at bottom while zoomed in r=layout-reviewers,hiro

Comment 28

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/0a7faf975d3f

Comment 29

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/d154d7fdf800