1918178 - Blank space between fixed-position footer and keyboard, when dynamic toolbar (address bar) has been scrolled out of view, with "resizes-visual" configuration

Status: RESOLVED FIXED

(Fenix :: Toolbar, defect, P2)

Description

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

Steps to reproduce

1. Load attached testcase.
2. Focus the textfield (so the keyboard appears)
3. Scroll to the end of the document (keeping the keyboard in view)

Expected behavior

• There shouldn't be any space beyond the cyan footer.
• In particular, no red should be visible.

Actual behavior

• There is some blank space beyond the cyan footer.
• ...which means red shows up in that blank space when you scroll to the end.

Device information

• Firefox version: 132.0a1
• Android device model: Pixel 6a
• Android OS version: 15

Any additional information?

This is sort of a version of bug 1908249, but this version is just specific to the fixed-position viewport, I think.
This bug is responsible for the still-reproducible part of an issue on the website for Zoom (zoom.us), in bug 1909872 comment 2.

Comment 1

[Petru-Mugurel Lingurar [:petru]]

Any recommendation on how to approach this while not impacting bug 1916154?
Seems like if from Fenix we update what the height of the toolbar can be we'd regress 1916154, if not we have this kind of issues.
If merging the patches proposed from bug 1916154 we'd still allow for either of these problems to show.

Maybe you know better how big this issues are in real life, how many websites would be affected
But seems to me more and more like we need to prioritize fixing both general issues either

• with new APIs from Gecko
• with product/UX deciding to allow showing also the navbar when the keyboard is opened.

Thoughts?

Comment 2

[Daniel Holbert [:dholbert]]

I'll defer to hiro on suggestions for comment 1, since he's got more context about the internal details of the various viewports and the internals/implications of toolbar-hiding than I am.

But I'll note one thing that I'm observing when retesting this today, which probably impacts the way we think about this: this bug actually reproduces regardless of whether the navbar is enabled. (I confirmed that in Nightly now that I know how to disable the navbar in secret-settings menu.) I had initially assumed this was navbar-related due to the similar feel to bug 1908249 (which is navbar-related), but it seems that this bug here may be a distinct issue.

Two notes though:

Maybe you know better how big this issues are in real life, how many websites would be affected

Any website that has bottom:0 fixedpos content (whether for a small footer or a full-screen overlay) and also has textfields would hit this. Probably not in a way that would prevent the site from being usable, but in a way that looks broken at least.

This is reasonably common; plenty of sites have bottom-bars or overlays of some sort.

with product/UX deciding to allow showing also the navbar when the keyboard is opened.

(I'm not a product/UX person, but I suspect this decision is unlikely -- screen real-estate is quite constrained and limited when the keyboard is up, particularly for small phone screens, so any UI that we show needs a strong justification to be there. The address bar has some security/anti-phishing value from a sec perspective, to confirm site-identity as you begin typing a password, for example; but the navbar has no strong reason to be present when the user is typing into a textfield, that I can think of.)

Comment 3

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #2)

But I'll note one thing that I'm observing when retesting this today, which probably impacts the way we think about this: this bug actually reproduces regardless of whether the navbar is enabled.

There were actually several distinct regressions here.
("good" = expected-results, "bad" = actual results, after performing the STR from comment 0. w/ = with, w/o = without.)

• Regression 1:
  Nightly 2024-08-28: good without navbar, good with navbar.
  Nightly 2024-08-29: bad without navbar, good with navbar.
  Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5c6272143175&tochange=644a484b60cb
  (In that pushlog, this was from bug 1884807 -- I confirmed that by toggling the resizes_visual about:config pref to false, and that makes Nightly 2024-08-29 become "good" without navbar rather than "bad".)

• Regression 2:
  Nightly 2024-09-09: bad without navbar, good with navbar.
  Nightly 2024-09-10: bad without navbar, bad with navbar.
  Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=50016ed27344&tochange=ebf0e33ba93e
  (I'm not sure offhand which change in that pushlog would have caused the regression in the "with-navbar" configuration to go from good to bad here)

Regardless, though: in contrast to my initial assumptions in comment 0, this bug is not navbar-specific, and instead, this bug is specific to the "resizes-visual" configuration. This bug goes away if I toggle dom.interactive_widget_default_resizes_visual to false.

Comment 4

[Daniel Holbert [:dholbert]]

--> clarifying bug summary to better-reflect what seems to really be going on (and that this is related to resizes-visual and not really related to navbar)

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1884807

Comment 6

[Ryan VanderMeulen [:RyanVM]]

Tracking+ for 132 since bug 1916002 is making resizes-visual ride the trains.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

The bug is marked as tracked for firefox132 (nightly). However, the bug still isn't assigned and has low severity.

:royang, could you please find an assignee and increase the severity for this tracked bug? Given that it is a regression and we know the cause, we could also simply backout the regressor. If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Comment 8

[Petru-Mugurel Lingurar [:petru]]

(In reply to Daniel Holbert [:dholbert] from comment #2)

But I'll note one thing that I'm observing when retesting this today, which probably impacts the way we think about this: this bug actually reproduces regardless of whether the navbar is enabled. (I confirmed that in Nightly now that I know how to disable the navbar in secret-settings menu.) I had initially assumed this was navbar-related due to the similar feel to bug 1908249 (which is navbar-related), but it seems that this bug here may be a distinct issue.

Testing this I see that it reproduces with both version of the toolbar, but only if the toolbar is dynamic - scrollable.
If the toolbar is fixed then the issue does not reproduce.

Comment 9

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1884807

Comment 10

[Botond Ballo [:botond]]

We discussed this bug during today's APZ meeting.

• It's unclear whether we can fix this for 132.
  • A proper fix may require bug 1921339 which is planned but a larger piece of work likely several months out.
  • A more targeted fix is under investigation but we're not sure about its risk level / suitability for uplift to 132 at this point.
• Given the number and severity of the webcompat problems that resizes-visual fixes, we would prefer to avoid delaying its release.
  • When we moved up the release schedule of resizes-visual (cc @jrmuizel on this topic), we did it with the awareness that we may have to temporarily accept some regressions which are less severe than the webcompat problems it's fixing. Bug 1915508 and bug 1915509 were known bugs in this category, and we feel this bug is in a similar boat.

Given the above, could we reconsider the tracking status of this bug, and make it fix-optional instead?

Comment 11

[Ryan VanderMeulen [:RyanVM]]

I conferred with Daniel and he agrees with your assessment. Thanks for the ping.

Comment 12

[Hiroyuki Ikezoe (:hiro)]

I did over-restrict this change in bug 1831649 when I implemented interactive-widget.

The code is to trigger a reflow on position:fixed frames to render the position:fixed frames at the proper position when the dynamic toolbar is completely hidden or fully visible. In bug 1831649 I overlooked such cases happen only interactive-widget=resizes-content cases or cases where the software keyboard is NOT visible. But as you can see this bug, such cases also happen with interactive-widget=resizes-visual.

A patch is coming.

Comment 13

[Hiroyuki Ikezoe (:hiro)]

Attachment: Bug 1918178 - Flush position:fixed elements' frames unconditionally when the dynamic toolbar is completely hidden or fully visible. r?botond

Unfortunately we can't write any automated tests for this bug as of now since

a) GeckoView test runnner doesn't support dynamic toolbars, thus we can't use
reftest or mochitest here.
b) JUnit test can handle dynamic toolbar movements, but the software keyboardu
doesn't appear in JUnit test for some reasons.

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5e9bb01911e6
Flush position:fixed elements' frames unconditionally when the dynamic toolbar is completely hidden or fully visible. r=botond

Comment 15

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/5e9bb01911e6

Comment 16

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:hiro, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox132 to wontfix.

For more information, please visit BugBot documentation.

Comment 17

[Hiroyuki Ikezoe (:hiro)]

Looks like the patch didn't fix the issue completely. I might have dropped some important parts of the change. :/

Comment 18

[Hiroyuki Ikezoe (:hiro)]

Attachment: Bug 1918178 - Factor out assertScreenshotResult. r?#geckoview-reviewers

Comment 19

[Hiroyuki Ikezoe (:hiro)]

Attachment: Bug 1918178 - Expand the layout viewport and shift position:fixed/sticky items in APZ only if it's necessary. r?botond!,#geckoview-reviewers

On non resizes-content modes while the software keyboard is shown, the layout
viewport is unchanged, thus any position:fixed or sitcky elements which are
stuck the root scroller don't need to be moved in response to the dynamic
toolbar movement.

Comment 20

[Hiroyuki Ikezoe (:hiro)]

Attachment: Bug 1918178 - Propagate interactive-widget mode and the software keyboard state to APZ. r?botond

Comment 21

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6ddee03f785a
Factor out assertScreenshotResult. r=geckoview-reviewers,m_kato
https://hg.mozilla.org/integration/autoland/rev/746bb1a3e20d
Propagate interactive-widget mode and the software keyboard state to APZ. r=botond
https://hg.mozilla.org/integration/autoland/rev/a71e6ad57971
Expand the layout viewport and shift position:fixed/sticky items in APZ only if it's necessary. r=botond,geckoview-reviewers,owlish

Comment 22

[Sandor Molnar[:smolnar]]

Backed out for causing reftest failures

Backout link: https://hg.mozilla.org/integration/autoland/rev/f8047162f57463ca16a04358355c2a6be8e18037

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&selectedTaskRun=NE55eXa-SsmDYwbix9cGLA.0&resultStatus=testfailed%2Cbusted%2Cexception&revision=a71e6ad5797190a1d6d9e62252364f4300cbb395&searchStr=reftest

Failure log: https://treeherder.mozilla.org/logviewer?job_id=480010496&repo=autoland&lineNumber=2917

Comment 23

[Hiroyuki Ikezoe (:hiro)]

It is likely there are some reftests which open the software keyboard and the keyboard keeps opening there. :/

Comment 24

[Hiroyuki Ikezoe (:hiro)]

Attachment: Bug 1918178 - Set inputmode="none" to avoid opening the software keybaord in selection.html and selection-ref.html. r?masayuki

Comment 25

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d3506f6cff62
Factor out assertScreenshotResult. r=geckoview-reviewers,m_kato
https://hg.mozilla.org/integration/autoland/rev/5a51de3207b4
Propagate interactive-widget mode and the software keyboard state to APZ. r=botond
https://hg.mozilla.org/integration/autoland/rev/e6bd5ecd1169
Expand the layout viewport and shift position:fixed/sticky items in APZ only if it's necessary. r=botond,geckoview-reviewers,owlish
https://hg.mozilla.org/integration/autoland/rev/df19e86f5cd1
Set inputmode="none" to avoid opening the software keybaord in selection.html and selection-ref.html. r=masayuki

Comment 26

[amarc]

https://hg.mozilla.org/mozilla-central/rev/d3506f6cff62
https://hg.mozilla.org/mozilla-central/rev/5a51de3207b4
https://hg.mozilla.org/mozilla-central/rev/e6bd5ecd1169
https://hg.mozilla.org/mozilla-central/rev/df19e86f5cd1

Comment 27

[Donal Meehan [:dmeehan]]

Hiro, given the size of the change, it looks like this should ride the trains with Fx134? i.e. wontfix for Fx132 and Fx133.
Please let me know if you think otherwise?

Comment 28

[Hiroyuki Ikezoe (:hiro)]

Yep.