1610959 - viewport size with top dynamic toolbar looks wrong

Status: RESOLVED WORKSFORME

(GeckoView :: General, defect)

Description

[__oldboek]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:74.0) Gecko/20100101 Firefox/74.0

Steps to reproduce:

Open http://bokand.github.io/demo/urlbarsize.html

https://github.com/mozilla-mobile/fenix/issues/6940

Actual results:

Those bars are covered by the bottom edge.

We need at least to call setDynamicToolbarMaxHeight and need a new API similar to setVerticalClipping.

Expected results:

The size of bars containing "percentage-based" should be bit shorter than visible content area.

Comment 1

[Hiroyuki Ikezoe (:hiro)]

(In reply to Jeff Boek [:boek] from comment #0)

We need at least to call setDynamicToolbarMaxHeight and need a new API similar to setVerticalClipping.

For clarification, the new API should cover both of top and bottom toolbars so the arguments should have at least two, top and bottom values.

Comment 2

[James Willcox (:snorp) ([e-mail]) (he/him)]

The plan was to just translate the GeckoView for top toolbars while using the existing setVerticalClipping API, but maybe that wasn't communicated very well. Jeff, can we try that? Hiro, does that sound reasonable to you?

Comment 3

[Hiroyuki Ikezoe (:hiro)]

Attachment: Another example to show something wrong layout

Attaching file has two position:fixed elements, one is top:0px, the other one is bottom:0px.

I was thinking that the top fixed element is not aligned with the top dynamic toolbar, but it's actually aligned perfectly. Instead some part of the bottom fixed element is laid out off browser window. So, what I can tell is we at least need to call setDynamicToolbarMaxHeight in Fenix so that the bottom fixed element will be aligned at the bottom of the window edge. But it's quite hard to tell what happens during the top dynamic toolbar is transitioning to hidden state, I am a bit worried, it looks like any APZ stuff is not involved at that time, (it is being scrolled by some Android components?) so setVerticalClipping might not help at all.

Jeff, can you please try add a setDynamicToolbarMaxHeight call in Fenix to see what happens? The place to call it is probably here at the last of initializUI.

Comment 4

[Hiroyuki Ikezoe (:hiro)]

I tried to add the setDynamicToolbarMaxHeight call.

https://github.com/hiikezoe/fenix/commit/ffa236ec7eb1e8ef4a69718ba313a088b2e94f3c

This commit fixes both of the case in comment 3 and comment 1. One caveat is that EngineViewBottomBehavior.kt in the commit is almost copied from EngineViewBottomBehavior.kt in android-comenponents, it should be renamed to a proper name and moved into android-components.

It seems that there is nothing to do in Gecko.

Comment 5

[Hiroyuki Ikezoe (:hiro)]

Emily, would you mind elaborate why this is WORKSFORME? If something has been changed in Fenix repository, can you please put links to the changes here?

Comment 6

[Emily Toop (:fluffyemily)]

I resolved WORKSFORME because it looks like there is no work to be done in Gecko or GeckoView and the only fixes required are in Fenix which can be done under the related Fenix issue. Therefore this issue requires no work from us and should be closed. If this is a mistake, I am sorry that I misunderstood and we can reopen this bug.

Comment 7

[Hiroyuki Ikezoe (:hiro)]

Ah I see. That makes sens. I was misunderstanding the issue on Fenix it self has been resolved there for some reasons.. Thanks for the clarification. :)

Comment 8

[Chris Peterson [:cpeterson]]

Moving toolbar bugs to the new GeckoView::Toolbar component.