Update splashscreen background color to match application's set theme
Categories
(Firefox for Android :: Design System and Theming, enhancement)
Tracking
()
People
(Reporter: petru, Assigned: petru)
References
(Depends on 1 open bug)
Details
(Whiteboard: [fxdroid][group3])
Attachments
(2 files, 2 external files, 1 obsolete file)
Idea got from a conversation about the isSystemInDarkTheme API - https://kotlinlang.slack.com/archives/CJLTWPH7S/p1726654545685589?thread_ts=1726652145.491239&cid=CJLTWPH7S
Looks like a new API in UIModeManager - setApplicationNightMode allows to persist the application's dark theme outside of the lifecycle of AppCompatDelegate.setDefaultNightMode.
And this allows to automagically use the matching background for our splashscreen.
| Assignee | ||
Comment 1•2 years ago
•
|
||
What the result would be in Fenix debug vs current Nightly, both set to dark theme while the device uses light theme.
| Assignee | ||
Updated•1 year ago
|
| Assignee | ||
Comment 2•1 year ago
|
||
Updated•1 year ago
|
| Assignee | ||
Updated•1 year ago
|
Updated•1 year ago
|
| Assignee | ||
Comment 5•1 year ago
|
||
This reverts commit f26d0b8c729b1c0f0c102be4873dc024bb7bceb5.
Comment 6•1 year ago
|
||
Comment on attachment 9444937 [details]
Revert "Bug 1919488 - Persist night theme changes on Android S+" r=#android-reviewers
Revision D232832 was moved to bug 1938824. Setting attachment 9444937 [details] to obsolete.
| Assignee | ||
Comment 7•1 year ago
|
||
In the case of theme changes that trigger an UI mode change applies in the application
after the current activity is restarted it should also apply the new ui mode to it's
configuration.
Comment 9•1 year ago
|
||
| bugherder | ||
| Assignee | ||
Updated•1 year ago
|
Comment 10•1 year ago
|
||
A patch has been attached on this bug, which was already closed. Filing a separate bug will ensure better tracking. If this was not by mistake and further action is needed, please alert the appropriate party. (Or: if the patch doesn't change behavior -- e.g. landing a test case, or fixing a typo -- then feel free to disregard this message)
Comment 11•1 year ago
|
||
For the future, it would have been cleaner if the new patch had landed in bug 1938824 so we can better track cause and effect (that bug is now both effectively caused and fixed by the same bug #).
Comment 12•1 year ago
|
||
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Comment 13•1 year ago
|
||
This is the current behavior on the latest Nightly 135.0a1 build from 12/27:
- the device's theme is different from the app's theme,
- when opening the app, the splashscreen has the same background as the device's.
Tested with Oppo Find N2 Flip (Android 14), Realme GT Master Edition (Android 13), and google Pixel 6 (Android 15).
Removing the qe-verify+ flag for now.
Updated•1 year ago
|
Comment 14•1 year ago
|
||
Comment 15•1 year ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/35b9fb7dc782
https://hg.mozilla.org/mozilla-central/rev/ddd04bc48281
| Assignee | ||
Comment 16•1 year ago
|
||
@ QA These patches were previously reverted.
After being merged back please help verify here and in bug 1916300 that the splashscreen has the right background color on Android 12+ and no ill effects are observed.
Comment 17•1 year ago
|
||
Thanks Petru,
Verified on multiple devices with the Fenix Nightly 136.0a1 from 1/9.
Everything looks good on Google Pixel 6 (Android 15), Samsung Galaxy S24 (Android 14), Oppo Find N2 Flip (Android 14), Vivo v23 (Android 14). The splashscreen follows Fenix' theme, even when the device's theme is different.
However on some devices, the difference between the device's theme and the app's theme messes up the UI in Settings - I filed Bug 1940902.
| Assignee | ||
Comment 18•1 year ago
|
||
The newly reported regression seems to show a race from setting both the selected theme here and the selected locale.
Seems like something specific to our implementation of in-app locale switching so I recommend re-evaluating supporting the splashscreen color updates only after moving to the new APIs for per-app language preferences that we have planned in bug 1813857.
Comment 19•1 year ago
|
||
This was reverted again in bug 1940902.
| Assignee | ||
Comment 20•1 year ago
|
||
Thanks Ryan!
Yeah, this seems too unstable in the context of other configurations that we have.
After bug 1813857 the implementation should be more straight-forward - no conflict with also applying locale changes.
Description
•