fix(web): keep iOS Safari status bar a consistent navy across pages#54
Open
ginoleeswan wants to merge 1 commit into
Open
fix(web): keep iOS Safari status bar a consistent navy across pages#54ginoleeswan wants to merge 1 commit into
ginoleeswan wants to merge 1 commit into
Conversation
In a plain iOS Safari tab the top status-bar strip and the bottom toolbar are both tinted from the document <body> background. Each web screen was painting the body its own content colour via useScreenChrome's `canvas` (beige on content pages, navy on Explore), so the system chrome flipped per page — the status bar went beige on the character page and navy on Explore. The theme-color meta + AdaptiveStatusBarCover that were meant to hold the top dark only take effect in a Home-Screen/standalone install, not a normal tab. Pin <body>/<html> to the app's deep-navy on every route so the status bar and bottom toolbar read a consistent dark everywhere. Light screens keep their beige look by painting it on their own container. Because the body is now navy, any light container clamped to one viewport (flex:1, which RNW pins to 100dvh via min-height:0) would leak navy under the content past the fold. Give every light canvas container a full-height beige fill (minHeight:100dvh, growing with content) so beige backs the whole scroll — verified in Chromium that flex:1 leaves ~1556px un-backed below the fold while minHeight:100dvh backs the full document height. Screens fixed: character, profile (mobile+desktop), biography (desktop), legal, title, issue. Explore/Search/Versus/Arena/category/team already use a dark canvas. The bottom content flow-through is preserved; only the system chrome + overscroll gutters read navy (per product decision). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017yG9ADfyP9B9MvageS3FL7
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What & why
On mobile iOS Safari the top status-bar strip (time/battery) changed color as you moved between pages — beige on the character detail page, dark navy on Explore.
Root cause: In a plain Safari tab, the top status-bar strip and the bottom toolbar are both tinted from the document
<body>background — this is Safari's own chrome, which no in-page element can repaint and which ignores the app's dynamictheme-colormeta. Each screen was painting<body>its own content color viauseScreenChrome'scanvas(beige on content pages, navy on Explore), so the system chrome mirrored whatever page you were on. The existingAdaptiveStatusBarCover+theme-colormachinery only takes effect in a Home-Screen/standalone install, not a normal tab. And because the top and bottom bars share the same<body>source, a two-tone "dark top / beige bottom" is not achievable in a tab.Decision: consistent navy chrome everywhere (top + bottom), preserving the bottom content flow-through.
Changes
<body>/<html>to the app's deep-navy on every route.useScreenChromeno longer repaints the body with each screen's content color, so the status bar + bottom toolbar read a consistent navy on every page. (src/hooks/useScreenChrome.ts,app/+html.tsx)flex:1, which RNW pins to 100dvh viamin-height:0) would show navy under the content below the fold. Each light screen's canvas container now uses a full-height beige fill (minHeight:'100dvh', grows with content) so beige backs the entire scroll. Fixed screens: character, profile (mobile + desktop), biography (desktop), legal, title, issue.The bottom content flow-through is preserved — only the system chrome and overscroll gutters read navy, which is the intended tradeoff.
Verification
flex:1leaves ~1556px below the fold un-backed by the beige canvas (where navy would leak), whileminHeight:'100dvh'backs the full document height (leak = 0).minHeight:'100dvh' … } as objectpattern from the auth screens.yarn test:ci/tscin the CI sandbox (registry bulk-fetch is blocked by egress policy); the diff touches only web view styles and a web-only hook.On-device note
Privacy/Terms (legal) pages declare a light top but will now get a navy status bar like every other page — consistent with "navy everywhere," but worth an eyeball if a different treatment is wanted there.
🤖 Generated with Claude Code
https://claude.ai/code/session_017yG9ADfyP9B9MvageS3FL7
Generated by Claude Code