fix(highlights): land the opened highlight below the status bar and header

[idoshamun]

Problem

On iPhone, tapping a headline in the in-feed Happening Now card opens /highlights?highlight=<id>, which expands that highlight and scrolls to it. The scroll ignored the top safe area, so the headline's first line ended up under the status bar, and the phone shell block slides back over it on any scroll up.

Root cause

HighlightItem scrolled with scrollIntoView({ block: 'center' }) and the <article> had no scroll margin. Coming from the feed, the item mounts already expanded, and expanded items are often taller than a phone's visible area. Centering such an item puts its top above the safe-area inset (e.g. a 695px item in a 750px viewport lands at 28px, under a 47px status bar). scrollIntoView knows nothing about the fixed status-bar band or the shell block.

Fix

• Scroll to block: 'start'.
• Give the article a scroll margin that clears what covers the top: on phones --safe-area-top + --shell-top, the same pattern MainComment and TagDirectory use. From tablet up, the safe area plus the larger of the sticky 4rem tab bar and the layout's --sticky-header-offset.

On tablet and laptop the opened highlight now aligns just under the tab bar instead of being centered.

Testing

• HighlightItem.spec.tsx now asserts the scroll aligns to the start (fails before, passes after).
• Ran the webapp locally against production and opened a highlight via client-side navigation, iPhone 13 emulation with a 47px top inset. Before: the item's top settled at −1 / 2 / 28px (under the status bar). After: it settles at 143px, below the 47px inset and the 96px shell block, on both the navigation path and the in-page expand path. Tablet (768px) and laptop (1280px): the item lands right under the 64px tab bar / header.
• pnpm --filter webapp test, shared highlights tests, eslint and the strict typecheck on changed files all pass.

Reviewer: @idoshamun (the centered scrollIntoView was introduced in #5857).

This PR was written by Smith (AI) as part of a bug hunt.

🤖 Generated with Claude Code

Written by Smith (AI).

Preview domain

https://fix-highlight-scroll-safe-area.preview.app.daily.dev

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
daily-webapp	Ready	Preview	Oct 13, 2026 5:43pm UTC

[idoshamun]

Before/after evidence

Setup (both runs): headless Chromium 145, Playwright iPhone 13 device (touch, iOS UA), 390x750 viewport. Chromium reports env(safe-area-inset-top) as 0, so --safe-area-top was forced to 47px, the value an iPhone sets in standalone mode.

Steps: open / → scroll to the in-feed "Happening Now" card → tap the 3rd headline ("Character.AI files for bankruptcy…", which opens /highlights?highlight=<id>) → sample positions every 250ms for 3s while the smooth scroll settles.

Before (production, re-run 2026-10-13)

The scroll settles at scrollY=321 with the expanded item's top at 28px, above the 47px inset. The first line of the headline sits under the status bar.

Images, in order: the feed card before the tap, the page after the tap, and the same frame annotated (the red band marks the 47px safe area).

After (PR preview, head 779ca40)

Verified on the Vercel preview for this PR's head SHA, https://fix-highlight-scroll-safe-area.preview.app.daily.dev/. The scroll settles at scrollY=206 with the item's top at 143px. That matches the computed scroll-margin-top of 143px (47px inset + 96px shell block), so the headline lands clear of both the status bar and the shell block.

Images, in the same order as above.

Neighboring cases also checked on the preview:

• Phone with a 0px inset: top=96.
• Direct load of /highlights?highlight=<id>: top=143 with the 47px inset, 96 without.
• Scrolling up 60px after landing: the shell block slides back in without covering the item.
• Tablet (768x1024) and laptop (1280x800): top=64, flush under the 64px header or tab bar. On these sizes the item now aligns to the top instead of the center, as intended.

Not checked: a real iPhone or the native wrapper, iOS Safari's own smooth-scroll timing, Android, and the extension.

---

Smith (AI) wrote this comment. Verification was done by Smith's QA role.

Written by Smith (AI).