1977790 - Initial compose homepage and menu redesign have wrong purple colors on cold startup when last active tab was private

Status: VERIFIED FIXED

(Firefox for Android :: Homepage, defect)

Description

[Kestrel]

Attachment: Non-private homepage and menu using purple colors on initial startup

STR:

1. Enable "Compose Homepage" and "Menu Redesign" in secret settings on latest Android Nightly 142.0a1.
2. Enable the Light theme.
3. Set "Opening screen" to "Homepage".
4. Open a private tab.
5. Quit the app and swipe it away on recents list.
6. Open app from app drawer, noting homepage colors.
7. Open three-dot menu.

Expected:
Homepage and menu use Light theme colors (dark text with white background) in non-private mode.

Actual:
Homepage has low contrast white text against white background with some elements using purple background like private mode (only with "Compose Homepage" enabled). Three-dot menu appears purple like in private mode (only with "Menu Redesign" enabled).

Colors correct themselves after creating a new tab.

Unrelated to "Homepage as New Tab" setting.

Regression window:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=bd960f56caef55577124a0a19e2bb2d1c3cc04dc&tochange=65eb2fa40ed8d8981413940c991194cb2dc84030

Possibly regressed by Bug 1973324.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

:gl, since you are the author of the regressor, bug 1973324, could you take a look?

For more information, please visit BugBot documentation.

Comment 2

[Gabriel Luong [:gl] (ΦωΦ)]

This is a regression from https://phabricator.services.mozilla.com/D255455. We missed a call to settings().lastKnownMode = mode in removing setupBrowsingMode. This is affecting the Compose Theme in particular because it relies on settings().lastKnownMode = mode in FirefoxTheme to determine the browsing mode and theme to use.

The fix here is to set settings().lastKnownMode = it.mode around HomeActivity.kt#1286. This would emulate the previous setupBrowsingMode as seen in https://phabricator.services.mozilla.com/D255455.

Comment 3

[Gabriel Luong [:gl] (ΦωΦ)]

Attachment: Bug 1977790 - Invoke onModeChange callback on initialization of the browsing mode

• See https://bugzilla.mozilla.org/show_bug.cgi?id=1977790#c2 for context.
• Unify the modeDidChange and updateAppStateMode callbacks into a single onModeChange callback.
• Invoke onModeChange in the mode setter on init of DefaultBrowsingModeManager. This will set the secure window flags and also update the AppState.mode.
• Fixes a bug where AppState.mode would not be synchronized with the current browsing mode on app startup.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/7fd106d4ce95
https://hg.mozilla.org/integration/autoland/rev/e75148bd46ca
Invoke onModeChange callback on initialization of the browsing mode r=android-reviewers,devota

Comment 5

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/e75148bd46ca

Comment 6

[Mira Lobontiu (Android QA)]

Verified as fixed on the latest Firefox for Android Nightly 143.0a1 from 7/27 with a Pixel Tablet (Android 15), and an Oppo Find X3 Lite (Android 11).