mirror of
https://github.com/vitorpamplona/amethyst.git
synced 2026-08-09 16:14:40 +00:00
Vitor PamplonaandClaude Opus 4.8
43aebcca63
The embedded in-app browser and napplet/nSite surfaces rendered web content in the device theme, ignoring the app's DARK/LIGHT preference — a site with dark support stayed light when the app was dark (and vice versa). The full-screen activities had the same latent gap (they followed the device, not the app). Root cause: WebView's dark decision (prefers-color-scheme via algorithmic darkening) reads the context's THEME (?android:attr/isLightTheme), not just the Configuration uiMode. The off-window SurfaceControlViewHost surface context carries neither the host window's theme nor its night mode, so the renderer came up light. The old applyNightMode() used UiModeManager.setNightMode — a permission-gated no-op — so the theme never reached the WebView at all. Fix: build every embed/host WebView from nightThemedContext() — a ContextThemeWrapper over a forced-night/day Configuration with a DayNight theme, so the theme's isLightTheme resolves from the app's resolved theme. Shared in EmbedWebViewTheme.kt; used by NappletBrowserService, NappletHostService, NappletBrowserActivity, and NappletHostActivity. Removed the dead applyNightMode no-op from all four. (Verified on device with a throwaway SurfaceControlViewHost repro: config-only context does NOT work; setForceDark is a no-op at targetSdk 37; setApplicationNightMode does nothing; the DayNight ContextThemeWrapper is what flips the renderer, even across the cross-process embedded surface.) Device-verified: all four surfaces follow the app theme even when it differs from the device. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>