JavaScript port: getNativeTheme() can return themes that aren't in the bundle

[shai-almog]

HTML5Implementation.getNativeTheme() can return six theme resources, but only three of them exist in Ports/JavaScriptPort/src/main/webapp/assets/:

returned by getNativeTheme()	present in webapp/assets
/iOS7Theme.res	✅
/iPhoneTheme.res	✅
/android_holo_light.res	✅
/iOSModernTheme.res	❌ missing
/AndroidMaterialTheme.res	❌ missing
/androidTheme.res	❌ missing

The missing ones are not obscure branches — HTML5Implementation.java:4021 makes them the default for the modern theme mode:

String modern = isIOSLikeBrowser() ? "/iOSModernTheme.res" : "/AndroidMaterialTheme.res";

with a fallback at :4029 to android_holo_light.res / iOS7Theme.res.

Noticed while auditing what a JavaScript bundle actually ships. Logging every request from a running app (desktop Chromium) shows it fetching assets/iOS7Theme.res — i.e. the fallback, because the preferred modern theme isn't there to load. So the modern native theme silently never applies on the JavaScript port.

Either the three missing .res files should be added to the port webapp, or getNativeTheme() should stop offering names the port cannot resolve.

Unrelated to #5466, which only removes genuinely unused fixtures — it deliberately keeps all three themes that are present and reachable.

[shai-almog]

Closing — I misread this, and the behaviour I reported is by design.

HTML5Implementation.installNativeTheme() says so explicitly:

The JS-port default stays on the pre-existing legacy theme (Holo Light when the user agent is Android, iOS 7 on everything else) so legacy screenshot baselines remain comparable. Apps that want the modern Liquid Glass / Material 3 theme can opt in via ios.themeMode / and.themeMode / nativeTheme / javascript.native.theme.

So the console fetching assets/iOS7Theme.res on desktop Chromium is the intended default, not a failed lookup falling back.

My two specific errors:

1. I read the modern local at :4021 as the theme being loaded. It isn't — it is published as the cn1.modernThemeResource property so DualAppearanceBaseTest can install the platform-appropriate theme without duplicating the OS detection. The theme actually loaded comes from resolveNativeThemeResource(), which is hint-driven and defaults to legacy.
2. I treated webapp/assets/ as the place these must live. Themes/ is the single source of truth, and each target stages what it needs from there (maven/javase copies all six, maven/ios folds iOSModernTheme.res into nativeios.jar, maven/linux and maven/windows have stage-native-theme steps, BuildDaemon copies them into src/). Nothing is "missing" from the JS webapp by that design.

One factual observation I'll leave here rather than reopen as a claim, since the fallback in installNativeTheme() explicitly anticipates it ("partial build, missing mirror step"): IPhoneBuilder and AndroidGradleBuilder act on the theme-mode hints at build time, while JavaScriptBuilder has no theme staging. If a JS app opts in via javascript.native.theme, I don't see what would place iOSModernTheme.res / AndroidMaterialTheme.res into its bundle — but I haven't tested that path, and the graceful fallback means it degrades to legacy rather than breaking. Happy to check properly if it's worth a look.

Apologies for the noise. #5466 is unaffected: it only removes files nothing resolves, and deliberately keeps iOS7Theme.res, iPhoneTheme.res and android_holo_light.res.