[Findings](/findings/index.md) / UX-058

# Whether the toolbars hide depends on how fast you scroll, not how far

Open · medium severity · failure · Firefox on iPad

## What we saw

Dragging the page up slowly, by any distance, leaves the full toolbars in place: tab strip, address bar, about 230 px of a 1,640 px screen before the page starts (first screenshot). A flick hides them, leaving a thin address line (second screenshot), but a flick also scrolls the page by an amount the reader does not control, so it overshoots. Scrolling back to the place wanted risks the small upward scroll that brings the toolbars back (UX-057) and can focus the address bar (UX-056). It is hard to reproduce on demand because it depends on gesture speed.

![Firefox on iPad at the top of the newsroom front page after a slow scroll: the tab strip and full address bar take the top of the screen](/findings/img/UX-058-toolbars-full.webp)

_After a slow drag: the full toolbars stay, however far the page has moved._

![The same front page after a flick: only a thin address line above the newsroom header, the page scrolled well past where the reader was](/findings/img/UX-058-toolbars-collapsed-after-flick.webp)

_After a flick: the toolbars hide, and the page has scrolled past where the reader was._

## Why it matters

The reader cannot ask for the state they want. To read with the toolbars hidden they have to flick, lose their place, find it again carefully, and hope the correction does not undo the result. Every attempt takes attention away from the text, which is the opposite of what hiding the toolbars is for.

## The fix

For the browser: make the toolbar state depend on something the reader controls (distance scrolled, or a deliberate tap on the address line), the same every time, and offer a setting to keep the toolbars collapsed while reading. For the sites: nothing a page can do about the browser's chrome; keep our own sticky header small, since it is the part of the stack we own.

**What good looks like:** [EX-001 Safari on iPad hides its toolbars the same way every time, after a small scroll](/exemplars/EX-001.md).

## The record

| | |
| --- | --- |
| **Status** | Open |
| **Severity** | Medium |
| **Kind** | Failure: works against the reader |
| **Product** | [Firefox on iPad](/findings/?product=firefox-ipad), browser |
| **Where** | <https://newsroom.sgit.ai/> |
| **Problems** | [Unpredictable control](/findings/?problem=unpredictable-control), [Unexpected movement](/findings/?problem=unexpected-movement), [Lost screen space](/findings/?problem=lost-screen-space) |
| **Visibility** | [Intermittent](/findings/?visibility=intermittent): some readers, some of the time: depends on a gesture, a device or a state, and is hard to reproduce on demand |
| **Recommendation** | [Make it predictable](/findings/?recommendation=make-it-predictable): the same gesture always gives the same result, and the reader can set the state directly instead of coaxing it |
| **Area** | [Navigation](/findings/?area=navigation) |
| **Breaks** | [The same gesture gives the same result, so it can be learned](/principles/index.md#same-gesture-same-result) |
| **Observed** | 2026-10-18, not recorded |
| **Last checked** | 2026-10-18, not recorded |
| **Environment** | Firefox for iOS on an iPad, landscape, on the newsroom.sgit.ai front page (newsroom v0.12.120) |
| **Source** | [Reported by Dinis Cruz, 18 Oct 2026, with screenshots](/method/index.md#reports-from-readers) |

Previous: [UX-057 The toolbars come back on any small scroll up, taking screen and moving the page](/findings/UX-057.md)

Next: [UX-059 A security prompt that asks you to approve a command it does not explain, and cuts off](/findings/UX-059.md)