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

# Scrolling back up a little puts focus in the address bar and opens the keyboard

Open · high severity · failure · Firefox on iPad

## What we saw

Reading a long page, a small scroll back up brings the hidden toolbars back, the address field gets focus with its URL selected, and the on-screen keyboard opens over the bottom half of the page (second screenshot: the URL selected, Cancel showing, the keyboard covering the release table). Nothing on the page was tapped on purpose. A likely mechanism, not yet confirmed: the toolbar slides in under the finger mid-gesture, so the touch that was a scroll lands on the address field as a tap.

![Firefox on iPad after a small scroll up: the tab strip and address bar are back, the URL is selected for editing and the keyboard covers the lower half of the newsroom release history](/findings/img/UX-056-keyboard-after-scroll-up.webp)

_After a small scroll up: address field focused, URL selected, keyboard open. Nothing on the page was tapped._

## Why it matters

The reader was not asking to go anywhere, and loses half the screen to a keyboard. Worse, it looks like the page has a bug: the first reading was that the site had somehow started an edit. The browser's fault is charged to the site, and the reader's concentration is broken either way.

## The fix

For the browser: a scroll gesture never focuses the address field; only a deliberate tap on a toolbar that is already at rest does. For the sites: nothing a page can prevent, but worth knowing that readers will report it as our bug, so it is recorded here with its real owner.

## The record

| | |
| --- | --- |
| **Status** | Open |
| **Severity** | High |
| **Kind** | Failure: works against the reader |
| **Product** | [Firefox on iPad](/findings/?product=firefox-ipad), browser |
| **Where** | <https://newsroom.sgit.ai/admin/versions.html> |
| **Problems** | [Focus hijack](/findings/?problem=focus-hijack), [Unexpected movement](/findings/?problem=unexpected-movement), [Wrong culprit](/findings/?problem=wrong-culprit) |
| **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** | [Keep the UI still](/findings/?recommendation=keep-the-ui-still): nothing moves, appears or takes focus unless the reader asked for it; chrome that hides stays hidden until a deliberate gesture |
| **Area** | [Navigation](/findings/?area=navigation) |
| **Breaks** | [Nothing moves that the reader did not move](/principles/index.md#ui-stays-still) |
| **Observed** | 2026-10-18, not recorded |
| **Last checked** | 2026-10-18, not recorded |
| **Environment** | Firefox for iOS on an iPad, landscape, reading newsroom.sgit.ai/admin/versions.html (newsroom v0.12.120) |
| **Source** | [Reported by Dinis Cruz, 18 Oct 2026, with screenshots](/method/index.md#reports-from-readers) |

Previous: [UX-055 "Ask the article" has never run against a real on-device model](/findings/UX-055.md)

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