Prevent bottom of page from being swipable#73
Conversation
Leave a dead zone at the bottom of the swipe area so Android gesture navigation (swipe-up-from-bottom for home/app-switcher) is not intercepted as a game swipe. Replaces the fixed `height: 75vh` with `bottom: max(env(safe-area-inset-bottom), 50px)`, which respects OS-reported safe area insets and guarantees at least 50 px of dead zone on devices that don't report one. https://claude.ai/code/session_01GDtKKugiT7tdd2BFc51rdn
📝 WalkthroughWalkthroughThe swipe component's CSS was updated to anchor its vertical positioning to the bottom of the viewport using safe-area-inset values, replacing a fixed height calculation. This changes how the element adapts to screen constraints in responsive scenarios. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan
Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@src/styles/components/swipe.css`:
- Line 6: Add a plain fallback bottom before the current max() rule and add an
explicit fallback to env(); specifically, add a simple "bottom: 50px;"
declaration immediately before the existing "bottom:
max(env(safe-area-inset-bottom), 50px)" and change the env() call to include a
fallback like "env(safe-area-inset-bottom, 0px)" so the final advanced rule
becomes "bottom: max(env(safe-area-inset-bottom, 0px), 50px)"; this ensures
older browsers use 50px and browsers that support env()/max() apply the
safe-area inset.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 7d95fde3-94a8-496c-ad0d-57c3a436426e
📒 Files selected for processing (1)
src/styles/components/swipe.css
| opacity: 0; | ||
| width: 100%; | ||
| height: 75vh; | ||
| bottom: max(env(safe-area-inset-bottom), 50px); |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
What is current support (including Android WebView) for CSS env(safe-area-inset-bottom)and CSSmax()in property values, and are there known parsing/fallback caveats when combined asmax(env(...), 50px)?
💡 Result:
Support (as of March 2026)
env(safe-area-inset-bottom)
- Android WebView: supported since WebView 69 (Chromium 69). [2]
- Chrome / Chrome Android: supported since Chrome 69. [1]
- Safari / iOS Safari: introduced around Safari 11–11.1 (with older “partial” history on Safari 11). [1][2]
- Firefox (desktop/Android): supported since Firefox 65. [1][2]
Notes:
- On Android, safe-area insets are only meaningful when the embedding app/windowing mode provides insets; Android’s guidance confirms WebView forwards insets to CSS safe-area env vars. [3]
max() in CSS property values (CSS math function)
- Android WebView: supported starting Chromium/WebView 79 (because
min()/max()/clamp()land in Chromium 79). [4] - Chrome / Edge: supported since 79. [4]
- Firefox: supported since 75. [4]
- Safari: supported from 13.1 (earlier versions show partial/none). [4]
Caveats when using max(env(...), 50px)
-
If
max()isn’t supported, the whole declaration is invalid (dropped).
This is the big practical issue on older Safari / older Chromium/WebView. Use a fallback declaration before it, or gate with@supports. [4][5]Example pattern:
padding-bottom: 50px; /* fallback */ padding-bottom: max(env(safe-area-inset-bottom, 0px), 50px);
-
If
env()is supported but the variable is unknown/invalid at computed-value time, behavior can “snap” to initial/inherited (not “ignore the declaration”).
MDN notesenv()is accepted at parse time, but validity is checked after substitution; if invalid and no valid fallback is provided, you can end up with the property’s initial/inherited value. [5]
Mitigation: always include a valid fallback insideenv(…, <fallback>). -
Android edge-to-edge: using
env(safe-area-inset-bottom)in padding on bottom-fixed UI can cause performance/layout issues.
Chrome’s Android edge-to-edge guidance explicitly warns that patterns likepadding-bottom: env(safe-area-inset-bottom, …)on bottom-anchored elements can cause “layout thrashing” (and can affect how the browser UI animates). They recommend alternative patterns usingsafe-area-max-inset-bottom+calc()for performant animation with the “chin” behavior. [6]
In short: today, max(env(safe-area-inset-bottom, 0px), 50px) is fine on modern engines (Chromium/WebView ≥79, Safari ≥13.1, Firefox ≥75), but you still want a plain fallback declaration for older browsers, and on Android edge-to-edge you should be careful about using the dynamic inset in padding on bottom-fixed UI. [4][6]
Sources:
[1] Can I use: CSS env() function https://caniuse.com/css-env-function
[2] BCD feature: css.types.env.safe-area-inset-bottom (includes WebView Android 69) https://bcd-training.deno.dev/feature?id=css.types.env.safe-area-inset-bottom
[3] Android Developers: “Understand window insets in WebView” https://developer.android.com/develop/ui/views/layout/webapps/understand-window-insets
[4] Can I use: CSS math functions min/max/clamp https://caniuse.com/css-math-functions%2Ccss-variables
[5] MDN: env() parsing/computed-value behavior https://developer.mozilla.org/en-US/docs/Web/CSS/env
[6] Chrome Developers: Android edge-to-edge + safe-area inset guidance https://developer.chrome.com/docs/css-ui/edge-to-edge
🏁 Script executed:
cat -n src/styles/components/swipe.css | head -15Repository: Coteh/2048-clone
Length of output: 440
Add a CSS fallback for max() function support and explicit env() fallback parameter.
Line 6 uses max(env(safe-area-inset-bottom), 50px), but max() support only landed in WebView 79+, Chrome 79+, Firefox 75+, and Safari 13.1+. On older browsers, the entire declaration is dropped, leaving the swipe area without explicit bottom positioning. Add a plain fallback declaration before the advanced rule, and ensure env() includes an explicit fallback parameter.
Proposed CSS fix
.swipe-area {
position: absolute;
top: 25vh;
opacity: 0;
width: 100%;
+ bottom: 50px;
- bottom: max(env(safe-area-inset-bottom), 50px);
+ bottom: max(env(safe-area-inset-bottom, 0px), 50px);
background-color: lightgray;📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| bottom: max(env(safe-area-inset-bottom), 50px); | |
| .swipe-area { | |
| position: absolute; | |
| top: 25vh; | |
| opacity: 0; | |
| width: 100%; | |
| bottom: 50px; | |
| bottom: max(env(safe-area-inset-bottom, 0px), 50px); | |
| background-color: lightgray; | |
| } |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@src/styles/components/swipe.css` at line 6, Add a plain fallback bottom
before the current max() rule and add an explicit fallback to env();
specifically, add a simple "bottom: 50px;" declaration immediately before the
existing "bottom: max(env(safe-area-inset-bottom), 50px)" and change the env()
call to include a fallback like "env(safe-area-inset-bottom, 0px)" so the final
advanced rule becomes "bottom: max(env(safe-area-inset-bottom, 0px), 50px)";
this ensures older browsers use 50px and browsers that support env()/max() apply
the safe-area inset.
Leave a dead zone at the bottom of the swipe area so Android gesture
navigation (swipe-up-from-bottom for home/app-switcher) is not
intercepted as a game swipe.
Replaces the fixed
height: 75vhwithbottom: max(env(safe-area-inset-bottom), 50px),which respects OS-reported safe area insets and guarantees at least
50 px of dead zone on devices that don't report one.
https://claude.ai/code/session_01GDtKKugiT7tdd2BFc51rdn
Summary by CodeRabbit