Phone: the bottom navigation bar is too tall when a page opens, and takes its normal height only after scrolling #338

New issue

Closed

opened 2026-10-01 06:48:34 +00:00 by tiagoagueda · 0 comments

tiagoagueda commented

2026-10-01 06:48:34 +00:00

Owner

Reported from a phone, with Firefox. Not reproduced here: no desktop browser has a toolbar that hides on scrolling, so the causes below are read from the code and none is confirmed.

What happens

Below 768 pixels the main navigation is a bar fixed to the foot of the window (#299). When a page opens, the bar is taller than it should be. After scrolling through the page it has its normal height, and keeps it.

What the code does

The bar's height (assets/css/app.css, the @media (width < 48rem) block for .nav-main): fixed inset-x-0 bottom-0, a slot of at least min-h-12 whose label may wrap, and padding-bottom: max(0.25rem, env(safe-area-inset-bottom)). That padding is the only part of its height the browser decides.
The viewport (src/postulo/templates/base.html:5) is width=device-width, initial-scale=1, with no viewport-fit.
The bar's height is copied into --bottom-bar-height by measureHeader() in src/postulo/static/js/app.js, on load, on resize, when the fonts are ready and through a ResizeObserver. The page's bottom padding, scroll-padding-bottom and the failure alert read it, so a bar that is too tall also leaves too much room under the page's last line.
On scrolling, Postulo's own scripts change one thing: data-scrolled on the header, which adds a shadow (markScrolled()). Nothing the bar is sized by. So what changes the bar when the page scrolls is the browser.

Likely causes, none confirmed

The safe-area inset counted while the browser's toolbar shows. A phone browser hides its toolbar on scrolling. If the browser reports a bottom inset while its own toolbar is still on screen, the bar pads itself for the system's gesture area although the toolbar already stands between the two. Once the toolbar hides, the bar reaches the edge of the screen, where that padding belongs, and looks right.
A label on two lines until the font arrives. A wrapped label makes the bar "a line taller", in the stylesheet's own words. This would settle without scrolling, so it fits the report less well.
A slot on a second row. The bar is flex-wrap; if the window's width is reported narrower for the first layout, the last slot wraps under the others.

To find out

On the phone, through Firefox's remote debugging (about:debugging):

the computed padding-bottom and height of .nav-main when the page opens and after scrolling;
whether a label is on two lines, or a slot on a second row, before scrolling;
whether the browser's address bar is at the top or at the foot of the screen, and whether moving it changes anything;
the same page in another browser on the same phone;
the phone, its system and the Firefox version, added to this issue.

Fix

It depends on what is found. For the first cause: the inset should not count while the browser's own toolbar is under the bar, for example by applying it only where the page is drawn edge to edge. The measurement comes first.

Done when

On the phone that reported it, the bar has the same height when a page opens and after scrolling, with the browser's toolbar shown and hidden, and the room under the page's last line matches it.
tests/e2e/test_navigation_bar.py cannot hide a browser's toolbar, so the check is made by hand on a phone and what was measured is written here.

Related: #299, which made the bar, and #339.

Reported on 2026-10-01, from a phone.

Reported from a phone, with Firefox. Not reproduced here: no desktop browser has a toolbar that hides on scrolling, so the causes below are read from the code and none is confirmed. ## What happens Below 768 pixels the main navigation is a bar fixed to the foot of the window (#299). When a page opens, the bar is taller than it should be. After scrolling through the page it has its normal height, and keeps it. ## What the code does - **The bar's height** (`assets/css/app.css`, the `@media (width < 48rem)` block for `.nav-main`): `fixed inset-x-0 bottom-0`, a slot of at least `min-h-12` whose label may wrap, and `padding-bottom: max(0.25rem, env(safe-area-inset-bottom))`. That padding is the only part of its height the browser decides. - **The viewport** (`src/postulo/templates/base.html:5`) is `width=device-width, initial-scale=1`, with no `viewport-fit`. - **The bar's height is copied** into `--bottom-bar-height` by `measureHeader()` in `src/postulo/static/js/app.js`, on load, on resize, when the fonts are ready and through a `ResizeObserver`. The page's bottom padding, `scroll-padding-bottom` and the failure alert read it, so a bar that is too tall also leaves too much room under the page's last line. - **On scrolling, Postulo's own scripts change one thing:** `data-scrolled` on the header, which adds a shadow (`markScrolled()`). Nothing the bar is sized by. So what changes the bar when the page scrolls is the browser. ## Likely causes, none confirmed 1. **The safe-area inset counted while the browser's toolbar shows.** A phone browser hides its toolbar on scrolling. If the browser reports a bottom inset while its own toolbar is still on screen, the bar pads itself for the system's gesture area although the toolbar already stands between the two. Once the toolbar hides, the bar reaches the edge of the screen, where that padding belongs, and looks right. 2. **A label on two lines until the font arrives.** A wrapped label makes the bar "a line taller", in the stylesheet's own words. This would settle without scrolling, so it fits the report less well. 3. **A slot on a second row.** The bar is `flex-wrap`; if the window's width is reported narrower for the first layout, the last slot wraps under the others. ## To find out On the phone, through Firefox's remote debugging (`about:debugging`): - the computed `padding-bottom` and height of `.nav-main` when the page opens and after scrolling; - whether a label is on two lines, or a slot on a second row, before scrolling; - whether the browser's address bar is at the top or at the foot of the screen, and whether moving it changes anything; - the same page in another browser on the same phone; - the phone, its system and the Firefox version, added to this issue. ## Fix It depends on what is found. For the first cause: the inset should not count while the browser's own toolbar is under the bar, for example by applying it only where the page is drawn edge to edge. The measurement comes first. ## Done when - On the phone that reported it, the bar has the same height when a page opens and after scrolling, with the browser's toolbar shown and hidden, and the room under the page's last line matches it. - `tests/e2e/test_navigation_bar.py` cannot hide a browser's toolbar, so the check is made by hand on a phone and what was measured is written here. Related: #299, which made the bar, and #339. Reported on 2026-10-01, from a phone.

tiagoagueda added this to the 0.6.0 milestone

2026-10-01 06:48:34 +00:00

tiagoagueda added the

bug

interface

labels

2026-10-01 06:48:34 +00:00

tiagoagueda referenced this issue

2026-10-01 06:48:35 +00:00

Phone: search is offered twice, in the masthead and under the bottom bar's More; remove it from the bar #339

tiagoagueda referenced this issue from a commit

2026-10-04 09:26:55 +00:00