1927184 - [Toolbar Redesign] Gesture-style navbar is always black (but should match the Firefox UI-color), for users with Fenix navbar turned on

Status: NEW

(Fenix :: Toolbar, defect, P1)

Description

[Daniel Holbert [:dholbert]]

tl;dr:
In recent Nightlies (after bug 1922419 landed), with the Fenix navbar enabled and gesture-style system-navigation, the system navbar (thin strip at bottom of the screen) is now unconditionally black. That matched the UX design requests that we had in bug 1922419 comment 3, but per slack discussion, I think we want to walk that back, specifically for users with gesture-style navigation (which is notably the default), because the Android's gesture-style-navbar is generally expected to match the app's own color rather than feeling like a separate UI component.

Steps to reproduce

1. Be sure you've got Android configured for gesture-style navigation. (thin bar at the bottom of screen rather than a button-bar)
2. Install and open Firefox Nightly.
3. Be sure you have the Fenix navbar enabled. (It is by default in Nightly, unless you get opted into an experiment). If you need to enable it, use the Secret Settings menu to toggle it on.
4. Look at the bottom of your screen.

Expected behavior

The Android system-navbar is black (regardless of Firefox/system theme, and regardless of whether this is a purple private tab vs. regular tab).

Actual behavior

The Android system-navbar should match the Firefox UI color.

Device information

• Firefox version: 133.0a1 2024-10-24
• Android device model: Pixel 6a
• Android OS version: 15

Any additional information?

• When testing this, be sure you've got Nightly with datestamp 2024-10-24 i.e. yesterday or newer. The Play store isn't offering me that one yet, but I've tested it via mozregression (and it'll presumably go out via Play store soon).
• This is a regression with respect to previous Nightlies -- e.g. Nightly 2024-10-22 is "good". Flagging it as a regression from bug 1922419, though the new behavior is correct per the requests in that bug, and I think we're finessing the UX request now to restore the old behavior under these conditions.

Comment 1

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #0)

• This is a regression with respect to previous Nightlies -- e.g. Nightly 2024-10-22 is "good". Flagging it as a regression from bug 1922419, though the new behavior is correct per the requests in that bug, and I think we're finessing the UX request now to restore the old behavior under these conditions.

Notably, this is only a regression for users who have the Fenix navbar enabled. Users without Fenix's navbar enabled will get expected-results here (their system navbar will match the Firefox UI color, which @royang and I both confirmed in local testing today in trunk/nightly builds).

Given that the fenix navbar hasn't yet been turned on by default (beyond nightly), that means this isn't a release-channel-facing regression.

Comment 2

[Daniel Holbert [:dholbert]]

[adjusting bug summary to more clearly describe the problem and the config-that's-involved-here]

Comment 3

[Daniel Holbert [:dholbert]]

copypasting (with minor edits) some UX input from @aarjav to from slack, to capture the ideal goal we arrived at in the slack thread (aarjav please feel to correct or add finesse to this):

for the toolbar with the new fenix nav bar (not applicable to the old toolbar), the requirement is:

• If we use the OS gesture nav bar, we keep the colour of the OS nav bar the same as as Firefox nav bar.
• If we use the OS button nav bar, we make the colour of the OS nav bar use the system black.

Right now we don't reason about whether the OS nav-bar is gesture-style or button-style, and we just go with that second bullet-point. The first bullet-point is the new-behavior that we should ideally introduce here.

It may be tricky to reason about what style of navigation bar the OS is using (and dynamically react to configuration-changes); that might not be something that there's an API to readily detect, though I think there are somewhat-reliable ways to figure it out.

(@royang and @zmckenney are looking into our options for doing that now)

Comment 4

[Daniel Holbert [:dholbert]]

--> preemptively calling this wontfix for 133 since I don't think we're intending to land a fix before the 133 nightly-to-beta-merge that's coming up on Monday, and this is not a user-facing regression for release users per comment 1.

Comment 5

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

Set release status flags based on info from the regressing bug 1922419

Comment 6

[Roger Yang [:royang]]

Attachment: Bug 1927184 - Only use black OS nav bar if gesture navigation is not enabled.