1536222 - URL bar covers fixed elements at the bottom of the page

Status: RESOLVED DUPLICATE of bug 1516048

(GeckoView :: General, defect, P1)

Description

[Chris Peterson [:cpeterson]]

Randall filed this issue as an RB bug. Vesta says the fix requires some GV work, so I filed this GV bug as a placeholder.

https://github.com/mozilla-mobile/reference-browser/issues/464

Steps to reproduce

1. Go to http://bluemarvin.github.io/html/footer.html

Expected behavior
The bottom footer should be rendered above the URL bar.

Actual behavior
The URL bar is rendered on top of the fixed element at the bottom of the page:

Comment 1

[Sebastian Kaspari (:sebastian; :pocmo)]

@Eitan: Can this bottom bar problem be fixed in a similar way like bug 1515774 for the top app bar - or is this a completely unrelated issue?

Comment 2

[Eitan Isaacson [:eeejay]]

No, its a different issue. We need to change the fixed bottom position depending on the clipped viewport size. I would say this is a dup of bug 1516048. I'll comment there to outline the work that needs to happen.

Comment 3

[Hiroyuki Ikezoe (:hiro)]

Chris, just to confirm, the fixed position element is covered by the urlbar in the first place (I mean it's covered not during the urlbar transition)?

Comment 4

[Chris Peterson [:cpeterson]]

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

Chris, just to confirm, the fixed position element is covered by the urlbar in the first place (I mean it's covered not during the urlbar transition)?

That is correct. When the page is first loaded, the "Footer - Just scroll" element is covered by Fenix's and Reference Browser's urlbar. If you scroll the page, the urlbar will be hidden and the footer element is then visible.

Comment 5

[Hiroyuki Ikezoe (:hiro)]

Thanks, Chris. Now I installed the reference browser and I see what the issue is. In my opinion, the urlbar UI is odd. It appears when I scroll upward and disappears when I scroll downward. I think it should be the opposite behavior. I.e. it appears when the user scrolls down and disappears when the user scrolls up and dynamically transitions synchronously with the content scrolling (I suppose it's bug 1516048).

Comment 6

[Chris Peterson [:cpeterson]]

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

Now I installed the reference browser and I see what the issue is. In my opinion, the urlbar UI is odd. It appears when I scroll upward and disappears when I scroll downward. I think it should be the opposite behavior. I.e. it appears when the user scrolls down and disappears when the user scrolls up and dynamically transitions synchronously with the content scrolling (I suppose it's bug 1516048).

That url bar behavior is intentional, though the movement does look backwards. Scrolling down a page to read it is typical scrolling direction. We want to the url bar to be hidden then so the page can use the full screen. If you have UI suggestions or examples of other apps using dynamic toolbars that you prefer, I can pass them along to the Fenix UX team. Or you can share them with Vesta (vzare in Slack or email).

Do you think this bug should be closed as a duplicate of bug 1516048 or bug 1515980?

Comment 7

[Hiroyuki Ikezoe (:hiro)]

The UI what I have in mind is Chrome's urlbar when you hold a phone upside-down. I have no other idea to avoid covering position:fixed bottom elements.

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

Do you think this bug should be closed as a duplicate of bug 1516048 or bug 1515980?

As for dynamic toolbar changes, it's a dup of bug 1516048. But as for the issue in the initial state, I mean the position:fixed element is covered by the urlbar in the first place, it seems it's an issue in the reference browser itself, the reference browser should tell the size subtracting the urlbar height to Gecko, but I am not 100% sure because I don't know where we tell the size and where we define it.

Comment 8

[Chris Peterson [:cpeterson]]

67=wontfix. Fenix MVP will use GeckoView 68, so we don't need to uplift this fix to 67 Beta.

Comment 9

[Chris Peterson [:cpeterson]]

Eitan says this bug is a dupe of bug 1516048.