Clickable icon areas is inconsistent in Firefox Mobile

[benalleng]

Description
The clickable area of the users profile, search, home, and notifications is fixed in place on Mobile Firefox. It does not move as the address bar comes and goes

Steps to Reproduce
Scroll or navigate to make the address bar disappear in mobile Firefox and then attempt to click on the user, search, home, or notifications icon. Then click ~height of address bar above the icon

Expected behavior
The clickable area of the user's icon should follow the rest of the navbar

Screenshots
mobile screenshots are huge and I'm too lazy to make them img tags

Environment:
If you only experience the issue on certain devices or browsers, provide that info.

• Device: Google Pixel 4a
• OS: Android
• Browser Firefox v124.1.0

Additional context
Tested in chrome but the navbar on my browser there is at the top and I could not reproduce.

Tested as both logged in and anon

Post seems to have it's own unique behavior where the button is clickable both on and above the rendered button

Spamming the buttons occasionally seems to fix it

Footer styling is often impacted by the position css so perhaps that is a good place to start to see if it affected by absolute, fixed, or static

[huumn]

That's weird. I suspect it's a bug in firefox. We're not doing anything hacky here. The bottom nav isn't even position: fixed.

[benalleng]

It might be that something like position fixed is missing, here is a screenshot of the navbar on my device

some preliminary testing shows me that adding position: fixed;, fixes it but position stuff can get weird so i want to do a little more testing

[benalleng]

since I can't reproduce on chromium stuff it might be a moment when we go down @-moz-document hell lol

[huumn]

We definitely don't want it be position: fixed. As is, it's in the normal DOM flow using flex properties which is more adaptable (because coupling is looser as the element isn't overlayed on other elements).

[huumn]

here is a screenshot of the navbar on my device

I think this demonstrates this a bug in firefox. Perhaps doing something silly like bottom: 0px fixes it.

[benalleng]

It looks like there is already a style bottom: 0px; any reason you want to avoid postion: fixed; and adding margin-bottom: 52px; to the footer to prevent overlap?

[huumn]

Mostly because it's less of a hack imo:

As is, it's in the normal DOM flow using flex properties which is more adaptable (because coupling is looser as the element isn't overlayed on other elements)

---

Adding things like margin-bottom: 52px means should the sizes of things change, we need to change this value.

---

We don't know what the disease exactly is here yet and don't want to only treat the symptom. If we figure out why this occurs, we might be able to preserve the benefits of flex by doing some small tweak to workaround firefox's bug.

[benalleng]

ok, i'll keep looking at getting it to work, found a thread about some bugs with position sticky and flex, see what i can find there

[huumn]

Cool. There might be an alternative way to do this using display: grid or some other combo of things ... position: sticky seems to be pretty buggy in most mobile browsers. And I didn't put effort into finding the best way to do this. I just know fixed is a pain to maintain.

(related: the top sticky bar is now position: fixed because ios safari has a bug with sticky when the virtual keyboard is shown ... but that didn't require adding other margin/padding ... still, it'd be nice to not use fixed at all given we don't actually want an overlay. We want sticky DOM sections with a scrollable <main>.)

[benalleng]

I found this writeup https://www.freecodecamp.org/news/fixed-side-and-bottom-navbar-with-css-flexbox/ which involves making the parent wrapper, in our case, the <div id"__next"> have overflow-y:hidden and then the footer be a flex item at the bottom. This does allow us to avoid fixed or sticky postioning but I still need to work a little on refactoring the css as the <main> element needs overflow: auto;