dtourolle
c55ff45692
The bottom nav rendered under the Android navigation bar, and full-screen
playback controls spilled into unusable screen edges. It looked device-specific
(Motorola bad, Fairphone fine) but every device was equally unpadded — only the
intrusion differed: a tall opaque 3-button bar swallows the nav, a thin
translucent gesture pill overlaps harmlessly.
None of the app's safe-area handling was ever active, for two independent
reasons:
1. app.html had no `viewport-fit=cover`, so every `env(safe-area-inset-*)`
resolved to 0px — the padding in app.css and BottomUi was a no-op.
2. Android WebView maps only the *display cutout* into `env()`; the status bar
and navigation bar are never reported. With enableEdgeToEdge() and
targetSdk 36 (enforced from 35, opt-out ignored from 36) the WebView always
spans them, so CSS could not learn about them by any route.
WindowInsetsBridge now reads `systemBars() | displayCutout()` and publishes
`--jt-inset-*` CSS custom properties, both pushed on every inset change
(rotation, nav-mode switch, PiP) and pullable via `AndroidInsets.get()` — the
pull is required because the first inset pass lands before the document exists
and a page load wipes the pushed inline style. app.css folds them with `env()`
via `max()` into `--safe-*`, the only thing components may pad from.
Exactly one element owns each edge: the shell takes top/left/right, BottomUi
takes bottom (inside its surface box, so the colour extends behind the gesture
bar), and shellReservesBottomInset hands bottom back to the shell on routes with
no bottom UI. The full-screen players inset their control layers only, leaving
video and artwork edge-to-edge.
The theme's `fitsSystemWindows=true` claimed the opposite of what actually
happened — overridden at runtime, ignored at this target SDK — and is removed.
Also converts six nested `h-screen`/`min-h-screen` boxes to `h-full`: the shell
is `h-screen` *and* inset-padded, so its content box is `100vh - safe-top` and
any nested 100vh box overflows by exactly the inset (the library column would
have clipped its own BottomUi). A test guards against reintroduction.
31 lines
1.7 KiB
XML
31 lines
1.7 KiB
XML
<resources xmlns:tools="http://schemas.android.com/tools">
|
|
<!--
|
|
Base application theme.
|
|
|
|
This app is EDGE-TO-EDGE: MainActivity calls enableEdgeToEdge(), and
|
|
targeting SDK 36 makes it mandatory anyway (enforced from SDK 35, with the
|
|
opt-out ignored from SDK 36). The WebView therefore spans the whole window,
|
|
under the status bar, the navigation/gesture bar and the display cutout.
|
|
|
|
This theme used to declare `android:fitsSystemWindows=true` with a "don't
|
|
draw behind system bars" comment. That was never true: enableEdgeToEdge()
|
|
calls setDecorFitsSystemWindows(false) at runtime and wins, and the
|
|
platform ignores the attribute at this target SDK regardless. Leaving it
|
|
in only hid the fact that nothing was insetting the content.
|
|
|
|
Insets are handled where they can actually be honoured: WindowInsetsBridge
|
|
reads them and hands them to CSS as jt-inset custom properties.
|
|
See UR-066 / DR-112.
|
|
-->
|
|
<style name="Theme.jellytau" parent="Theme.MaterialComponents.DayNight.NoActionBar">
|
|
<!-- System bars are transparent; the app draws its own background behind
|
|
them (e.g. BottomUi's surface extends under the gesture bar). -->
|
|
<item name="android:statusBarColor">@android:color/transparent</item>
|
|
<item name="android:navigationBarColor">@android:color/transparent</item>
|
|
<!-- Light icons on our dark background, both bars. -->
|
|
<item name="android:windowLightStatusBar" tools:targetApi="m">false</item>
|
|
<item name="android:windowLightNavigationBar" tools:targetApi="o_mr1">false</item>
|
|
<item name="android:windowDrawsSystemBarBackgrounds">true</item>
|
|
</style>
|
|
</resources>
|