1920019 - The dynamic toolbar overlaps an active input field for certain page heights

Status: NEW

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

Description

[Alex Jakobi [:ajakobi]]

Attachment: interactive-widget-default.html

This regresses bug 1855990.

Hiding the toolbar wouldn't be the correct behavior. See comment #2 and comment #3

When the default mode for interactive-widget is set, the condition in AsyncPanZoomController::ZoomToRect does not evaluate to true because scrollableRectHeight is always larger than lvh. (reproducible with attached test page interactive-widget-default)

In contrast, when setting interactive-widget=resizes-content, the condition does evaluate to true and the toolbar can be hidden. Which as of now is only seen on GeckoView and will be available on Fenix when bug 1900622 is resolved. (reproducible with attached test page interactive-widget-resizes-content)

Comment 1

[Alex Jakobi [:ajakobi]]

Attachment: interactive-widget-resizes-content.html

Comment 2

[Hiroyuki Ikezoe (:hiro)]

I am assuming in the case of interactive-widget=resizes-visual, we don't need to hide the toolbar.

Comment 3

[Hiroyuki Ikezoe (:hiro)]

And moreover in the case of interactive-widget=resizes-visual, we should not change the dynamic toolbar height, since changing the height changes the layout viewport size, which means it violates the spec.

Comment 4

[Alex Jakobi [:ajakobi]]

That's good information. Should we then rather rephrase this bug to 'The dynamic toolbar overlaps an active input field for certain page heights'?

Comment 5

[Hiroyuki Ikezoe (:hiro)]

Yep, probably there needs some tweaks in scroll-into-view machinery if the input field isn't in the view.

Comment 6

[Petru-Mugurel Lingurar [:petru]]

Going by comment #5 this seems like something that would be handled entirely in Gecko.
Not sure how big the effort would be.
Given that this is an old bug/edgecase and I see the work on bug 1900622 is considered paused should these two tickets block the release of the navbar or can be seen as later improvements?

Comment 7

[Alex Jakobi [:ajakobi]]

See bug 1900622, comment #38: I don't think this should block the release of the navbar.

Comment 8

[Markus Stange [:mstange]]

Fenix could always hide the bottom toolbar whenever the keyboard is visible. This is what Safari does. I think that would fix this testcase.

Comment 9

[Petru-Mugurel Lingurar [:petru]]

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

Fenix could always hide the bottom toolbar whenever the keyboard is visible. This is what Safari does. I think that would fix this testcase.

This is an interesting approach though I think we have always shown the bottom toolbar on top of the keyboard - users are used to this and it does help with security - knowing exactly where you're typing a password for example.
Also we'd be left with issues similar to bug 1916154.