dtourolle/jellytau
1
0
Fork 0
Code Issues Pull Requests Actions 4 Packages Projects Releases 38 Wiki Activity

fix(android): clear the system bars and display cutout (UR-066)

Browse Source 
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.
This commit is contained in:
dtourolle
2026-08-04 14:45:10 +02:00
parent 58f2506966
commit c55ff45692
20 changed files with 790 additions and 33 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src-tauri/android/src/main/java/com/dtourolle/jellytau/MainActivity.kt
+19
View File
@@ -56,6 +56,14 @@ class MainActivity : TauriActivity() {
enableEdgeToEdge()
super.onCreate(savedInstanceState)
// enableEdgeToEdge() puts the WebView under the status bar, the navigation/
// gesture bar and the display cutout — and targeting SDK 36 makes that
// non-optional anyway. Android WebView never surfaces the *system bar*
// insets to CSS (only the display cutout), so the web layer has to be told.
// Without this the bottom nav renders underneath the navigation bar, badly
// so on devices with a tall opaque 3-button bar. (UR-066)
WindowInsetsBridge.install(this)
// Configure WebView for media playback after Tauri initialization
handler.postDelayed({
configureWebViewForMedia()
@@ -179,6 +187,12 @@ class MainActivity : TauriActivity() {
//
// The settings/WebChromeClient work below is idempotent and must keep
// running on resume; only the bridge injection is one-shot.
// Re-push the safe-area insets. Unlike addJavascriptInterface this is
// idempotent and MUST re-run: a page load discards the inline style the
// last push set, so the WebView would otherwise be left with no insets.
WindowInsetsBridge.attachWebView(webView)
if (webView === bridgesInstalledOn) {
android.util.Log.d("MainActivity", "JS bridges already installed on this WebView - skipping re-injection")
configureWebViewSettings(webView)
@@ -257,6 +271,11 @@ class MainActivity : TauriActivity() {
}, "AndroidNetworkType")
android.util.Log.d("MainActivity", "JavaScript interface 'AndroidNetworkType' added")
// Window insets (safe areas). The push path above races the page load, so
// the frontend pulls the current values on mount through this bridge.
webView.addJavascriptInterface(WindowInsetsBridge.jsInterface(), "AndroidInsets")
android.util.Log.d("MainActivity", "JavaScript interface 'AndroidInsets' added")
// Push network changes into the WebView so a queue blocked on "waiting for
// WiFi" resumes the moment an acceptable network appears.
NetworkTypeMonitor.startWatching(this) {
src-tauri/android/src/main/java/com/dtourolle/jellytau/WindowInsetsBridge.kt
+140
View File
@@ -0,0 +1,140 @@
package com.dtourolle.jellytau
import android.app.Activity
import android.webkit.JavascriptInterface
import android.webkit.WebView
import androidx.core.view.ViewCompat
import androidx.core.view.WindowInsetsCompat
/**
* Publishes the Activity's real window insets to the WebView as CSS custom
* properties.
*
* TRACES: UR-066 | IR-031, DR-112
*
* ## Why this is necessary
*
* MainActivity calls `enableEdgeToEdge()`, and the app targets SDK 36 —
* edge-to-edge is mandatory from SDK 35 and the opt-out is ignored from SDK 36
* — so the Tauri WebView always spans the whole window, underneath the status
* bar, the navigation/gesture bar and the display cutout.
*
* The web layer cannot discover that by itself. Android WebView maps only the
* **display cutout** into `env(safe-area-inset-*)` (and only with
* `viewport-fit=cover`); the status bar and navigation bar are never reported.
* Unlike iOS Safari there is no CSS-visible system-bar inset. So the frontend's
* `env()`-based padding evaluated to 0 on every device and the bottom nav
* rendered underneath the navigation bar.
*
* How badly that showed depended entirely on the device's navigation mode: a
* thin translucent gesture pill overlaps almost harmlessly, while a tall opaque
* 3-button bar swallows the nav outright.
*
* ## Contract with the frontend
*
* Insets are reported in **CSS pixels** (density-independent), because that is
* the unit CSS will use them in — dividing by `displayMetrics.density` here is
* what keeps the padding correct across screen densities.
*
* - **Push**: on every inset change (rotation, navigation-mode switch, PiP
* enter/exit) the four `--jt-inset-*` custom properties are written onto
* `document.documentElement` and `jellytau-insets-changed` is dispatched.
* - **Pull**: `AndroidInsets.get()` returns the same payload as JSON. Required
* because the first inset pass normally lands before the SvelteKit document
* exists, and a page load discards any inline style a push had set.
*
* See `src/lib/utils/safeArea.ts` and the `--safe-*` vars in `src/app.css`.
*/
object WindowInsetsBridge {
/** Latest insets in CSS pixels. Written on the main thread, read from the WebView binder thread. */
@Volatile
private var top = 0
@Volatile
private var right = 0
@Volatile
private var bottom = 0
@Volatile
private var left = 0
/** Cached so a WebView found later (or re-found on resume) can be primed. */
private var webView: WebView? = null
/**
* Start listening for window insets on [activity].
*
* Call from `onCreate` right after `enableEdgeToEdge()`. The listener
* returns the insets **unconsumed** so the WebView still receives them for
* its own display-cutout handling.
*/
fun install(activity: Activity) {
val density = activity.resources.displayMetrics.density
ViewCompat.setOnApplyWindowInsetsListener(activity.window.decorView) { _, insets ->
// systemBars() covers the status bar and the navigation/gesture bar;
// displayCutout() covers notches and punch-holes, which in landscape
// land on a side edge that systemBars() does not describe.
val i = insets.getInsets(
WindowInsetsCompat.Type.systemBars() or WindowInsetsCompat.Type.displayCutout()
)
val toCssPx = { px: Int -> if (density > 0f) Math.round(px / density) else px }
top = toCssPx(i.top)
right = toCssPx(i.right)
bottom = toCssPx(i.bottom)
left = toCssPx(i.left)
android.util.Log.d(
"WindowInsetsBridge",
"insets (css px): top=$top right=$right bottom=$bottom left=$left"
)
push()
// Do NOT return CONSUMED - other views (and the WebView's own cutout
// handling) still need to see these.
insets
}
// The first pass may already have happened before the listener existed.
ViewCompat.requestApplyInsets(activity.window.decorView)
}
/**
* Adopt the WebView carrying the UI and push the current insets into it.
*
* Safe to call repeatedly (MainActivity re-finds the WebView on every
* resume): this only writes CSS properties, unlike `addJavascriptInterface`,
* which must run exactly once per WebView.
*/
fun attachWebView(view: WebView) {
webView = view
push()
}
/** Current insets as JSON in CSS pixels — the payload `AndroidInsets.get()` returns. */
fun currentJson(): String =
"""{"top":$top,"right":$right,"bottom":$bottom,"left":$left}"""
/** The `AndroidInsets` @JavascriptInterface object for the pull path. */
fun jsInterface(): Any = object : Any() {
@JavascriptInterface
fun get(): String = currentJson()
}
/** Write the custom properties into the live document and signal the change. */
private fun push() {
val view = webView ?: return
val js = """
(function() {
var s = document.documentElement.style;
s.setProperty('--jt-inset-top', '${top}px');
s.setProperty('--jt-inset-right', '${right}px');
s.setProperty('--jt-inset-bottom', '${bottom}px');
s.setProperty('--jt-inset-left', '${left}px');
window.dispatchEvent(new CustomEvent('jellytau-insets-changed'));
})();
""".trimIndent()
view.post { view.evaluateJavascript(js, null) }
}
}
src-tauri/android/src/main/res/values/themes.xml
+23 -6
View File
@@ -1,13 +1,30 @@
<resources xmlns:tools="http://schemas.android.com/tools">
<!-- Base application theme -->
<!--
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">
<!-- Status bar color -->
<!-- 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>
<!-- Make status bar icons dark or light based on background -->
<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>
<!-- Don't draw behind status bar -->
<item name="android:windowLightNavigationBar" tools:targetApi="o_mr1">false</item>
<item name="android:windowDrawsSystemBarBackgrounds">true</item>
<!-- Ensure content doesn't extend into system bars -->
<item name="android:fitsSystemWindows">true</item>
</style>
</resources>