1916154 - viewport units size value is not correctly calculated with new nav bar while the software keyboard is visible

Status: RESOLVED FIXED

(Fenix :: Toolbar, defect, P2)

Description

[Hiroyuki Ikezoe (:hiro)]

Attachment: t.html

Steps to reproduce

1. Open the attaching file both on Firefox and Chrome and click the input element to see whether the green bar height is changed or not

Comment 1

[Chris Peterson [:cpeterson]]

Petru, do we need to fix this bug for the new navbar? Or are this bug and bug 1912008 only relevant for the new ScrollDelegate?

Comment 2

[Hiroyuki Ikezoe (:hiro)]

(In reply to Chris Peterson [:cpeterson] from comment #1)

Petru, do we need to fix this bug for the new navbar? Or are this bug and bug 1912008 only relevant for the new ScrollDelegate?

Both bugs are independent from the new ScrollDelegate-like API. This bug is a regression by the new nav bar, rather than pre-existing issue such as bugs which will be solved by the new ScrollDelegate-like API.

Comment 3

[Petru-Mugurel Lingurar [:petru]]

This bug is a regression by the new nav bar

Don't know the technicalities of how Gecko handles this but seems to me like the green bar is the height of the toolbar sent from Fenix through the setDynamicToolbarMaxHeight API. And this will differ between

• if the keyboard is opened - we only show the address bar, say 50px
• if the keyboard is closed - we show both the address bar and the navbar, say 50px + 50px

For this situations I think we should update the value through setDynamicToolbarMaxHeight but given the report here I'm curious why it is a problem? What are the implications? How often would users see a bug from this and then of course what is the proposed approach for fixing this?

I think Chris' concern (which I do share) was whether this should block the navbar release or not, hoping that answers to the above questions would help better understand this.

Comment 4

[Hiroyuki Ikezoe (:hiro)]

The setDynamicToolbarMaxHeight is not supposed to be called with two different values, other than being called with zero.

From what I can tell is that this bug affects all DOM element using viewport units such as vh, svh, lvh and dvh. So in the worst case there would there appear inaccessible elements while the software keyboard is visible. If there's such cases, I would say, this bug should be a blocker.

Comment 5

[Petru-Mugurel Lingurar [:petru]]

I understand the report here being closely related to bug 1908249 where the bug was that we were not updating the toolbar height through setDynamicToolbarMaxHeight and then doing so solves that issue which can also be seen for example on youtube where without which we would show it's bottom bar "in the air" when searching.
So looks like not updating setDynamicToolbarMaxHeight is not an option - the toolbar height does change and seems expected from us to inform the browser about this.

Seeing that this blocks bug 1912008 which would be a solution to support all discussed scenarios? should the priority of that be increased - can an estimation be made of the rough effort needed?
Otherwise the way I understand it we should not hide the navbar when the keyboard is showing which needs to be discussed with UX.

Comment 6

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

This bug has been marked as a regression. Setting status flag for Nightly to affected.

Comment 7

[Hiroyuki Ikezoe (:hiro)]

(In reply to Petru-Mugurel Lingurar [:petru] from comment #5)

I understand the report here being closely related to bug 1908249 where the bug was that we were not updating the toolbar height through setDynamicToolbarMaxHeight and then doing so solves that issue which can also be seen for example on youtube where without which we would show it's bottom bar "in the air" when searching.
So looks like not updating setDynamicToolbarMaxHeight is not an option - the toolbar height does change and seems expected from us to inform the browser about this.

But unfortunately there's another side that's not what web developers expect such as this bug.

Seeing that this blocks bug 1912008 which would be a solution to support all discussed scenarios? should the priority of that be increased - can an estimation be made of the rough effort needed?

I am afraid I can't tell I have fully grasped all possible scenarios affected by the new nav bar behavior, so it's hard to tell right now. A rough estimate is 1-month or so, maybe?

Otherwise the way I understand it we should not hide the navbar when the keyboard is showing which needs to be discussed with UX.

If we could chose this option, things might be easy.

Comment 8

[Petru-Mugurel Lingurar [:petru]]

Based on bug 1908249 comment 22 we can avoid this reverting the patch from that bug and accept that as a temporary smaller issue than this.

Comment 9

[Chris Peterson [:cpeterson]]

We need to fix this bug before the new nav bar rides the trains.

Comment 10

[Petru-Mugurel Lingurar [:petru]]

Attachment: Bug 1916154 - Avoid informing Gecko about toolbar height changes if resize visuals is enabled r=#android-reviewers

If using the navbar with a bottom toolbar when interacting with an input element in
a website the navbar will be hidden. Informing websites that the height of the toolbar
is now changed would allow them to update positioning of fixed elements.

Here we revert the patch for https://bugzilla.mozilla.org/show_bug.cgi?id=1908249 based
on the discussions there in an effort to avoid what can be a bigger issue (bug 1916154).
This would only be needed while waiting for Gecko to allow supporting both scenarios
possibly through new APIs.

Comment 11

[Petru-Mugurel Lingurar [:petru]]

Based on the recommendation from bug 1908249 comment 22 I reverted that patch to avoid the issue described here and added you Hiro as a reviewer since the issues here are more closer to web functionality and standards and you have better insights in these to appreciate the direction we need to go.
Thinking about what's next - do we have another ticket opened for APZ to add support for these related scenarios / should we open one?

Comment 12

[Hiroyuki Ikezoe (:hiro)]

Attachment: Bug 1916154 - Expose "dom.interactive_widget_default_resizes_visual" via GeckoRuntime. r?#geckoview-reviewers

Comment 13

[Hiroyuki Ikezoe (:hiro)]

As per Daniel's concern in bug 1908249 comment 23, the revert change should depend on "dom.interactive_widget_default_resizes_visual" value, now I posted D222892 to expose the pref via GeckoRuntimeSettings. It would be nice to handle the concern in this bug here, so that we don't need to worry about the another ticket in future.

Comment 14

[Petru-Mugurel Lingurar [:petru]]

Attachment: Bug 1916154 - Avoid informing Gecko about toolbar height changes if resize visuals is enabled r=#android-reviewers

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/86b6901d760e
Expose "dom.interactive_widget_default_resizes_visual" via GeckoRuntime. r=geckoview-reviewers,ohall,owlish

Comment 16

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/86b6901d760e

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/633fc71b17f5
Avoid informing Gecko about toolbar height changes if resize visuals is enabled r=android-reviewers,hiro,skhan

Comment 18

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/633fc71b17f5

Comment 19

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

The patch landed in nightly and beta is affected.
:petru, 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.