2074348 - Update menu UI

Status: VERIFIED FIXED

(Focus :: General, task)

Description

[Petru-Mugurel Lingurar [:petru]]

Attachment: FocusMenuBeforeAfter.png

We can use the new menu support from bug 2066831 to update to a modern UI on Focus also.

Comment 1

[Petru-Mugurel Lingurar [:petru]]

Attachment: Bug 2074348 - part 1 - Show the Compose menu while browsing r?#android-reviewers

Replaces the View based browser-menu with the compose-menu module, kept as a
popup anchored to the menu button rather than the bottom sheet other
applications use it for. "Desktop site" becomes a row with an On/Off badge and
the previous dividers become group boundaries.

The button is a ComposeView browser action of its own because DisplayToolbar
only shows its own button for a menuBuilder or a menuController. Its store is
built when the menu opens, so the browser state is observed for only as long as
the menu is shown.

Comment 2

[Petru-Mugurel Lingurar [:petru]]

Attachment: Bug 2074348 - part 2 - Show the Compose menu on the home screen r?#android-reviewers

Unlike the browser toolbar, which builds its actions in code, the home screen
declares its menu button in fragment_urlinput.xml, so the browser-menu
MenuButton view is replaced there with a ComposeView.

Comment 3

[Petru-Mugurel Lingurar [:petru]]

Attachment: Bug 2074348 - part 3 - Show the Compose menu in custom tabs r?#android-reviewers

CustomTabsToolbarFeature no longer gets a menuBuilder: both menus provide their
groups through MenuItems, leaving BrowserToolbarIntegration to pick which one to
build a store for.

Comment 4

[Petru-Mugurel Lingurar [:petru]]

Attachment: Bug 2074348 - part 5 - Move BrowserMenuController into MenuMiddleware r?#android-reviewers

BrowserMenuController existed to be shared by the XML menu and the Compose one.
With only the latter left, handling the menu items can live in the middleware and
BrowserFragment no longer needs to build the controller, passing in to the
middleware the same callbacks that need the fragment.

Comment 5

[Petru-Mugurel Lingurar [:petru]]

Attachment: Bug 2074348 - part 6 - Let the sticky menu group fill the width of the menu r?#android-reviewers

The sticky group holding the navigation icons was laid out with the same
horizontal and top padding as the scrolling groups, so its own background stopped
short of the menu edges and the group could still be scrolled up by the height of
that padding. The padding now applies only to the groups that scroll.

Comment 6

[Petru-Mugurel Lingurar [:petru]]

Attachment: Bug 2074348 - part 7 - Simplify the Compose menu layout r?#android-reviewers

The footer was overlaid on the content, so its measured height had to be fed back
as bottom padding for the list. Laying the two out in a Column with the list
taking the remaining height removes that round trip, along with the remembered
derivations of the header, footer and scrolling groups.

Also adds the tests Menu() did not have.

Comment 7

[Petru-Mugurel Lingurar [:petru]]

Attachment: Bug 2074348 - part 8 - Show an attribution in the menu r?#android-reviewers

Added support for menu integrators configuring the menu to show attribution text
at the top or bottom of the menu, like "Powered by ..", text which is more
helpful for custom tabs menus.

Comment 8

[breakingspell]

I am very impressed by this concept! The padding is excessive however, it could be reduced by several px.

I'm assuming that this linear menu design will be accessible in mainline Fenix, not just Focus?

Comment 9

[Sören Hentzschel]

I'm assuming that this linear menu design will be accessible in mainline Fenix, not just Focus?

This comment confuses me. Fenix has had this menu style for a long time. This is about adding that same menu style to Focus (where it would naturally have far fewer items, since Focus has fewer features).

Comment 10

[breakingspell]

Fenix has had this menu style for a long time

Fenix did have this style for a long time, but with BUG 1863790 and it's implementation around 7/2025, the Fenix context menu was redesigned from a linear list to a bottom-sheet drawer. This regressed one-handed usability and muscle memory, particularly for top-toolbar users. This is the most common feedback point on Connect regarding the new Android UX, across several discussions and idea threads.

The proposed menu in this ticket is a linear list. For context menus, this form factor is objectively suited over a bottom drawer: A user's eyes only have to scan along one directional axis to evaluate all options, while the two-dimensional menu drawer requires up-down-left-right movement of both eyes and hands.

Unless I've missed a ticket where this exact concept is implemented in Fenix, then yes: I'm proposing that this menu style be included in Fenix as well.

Comment 11

[Sören Hentzschel]

I don’t know what you mean by “linear list,” but again: this is the design from Fenix, except that this version apparently doesn’t span the full width and is anchored to the menu button. It just has less items because Focus has less features. Your comment about “one-handed usability” doesn’t make sense to me either: for that to be optimized, everything relevant would need to be at the bottom, unless you hold your phone in a very unconventional way.

In any case, this whole discussion is off-topic. This is an implementation ticket for Focus. Broader design discussions belong on Mozilla Connect.

Comment 12

[breakingspell]

Please do not mark this post as advocacy or off-topic, I am communicating specific design feedback directly to the developer.

This is already the most discussed topic on Mozilla Connect regarding the new Fenix UX (this this aggregated post groups the miscellaneous threads). However, the menu's form factor may have been forgotten while internally planning this customization work, which is why I'm being very specific on the ticket where a desirable design is being showcased.

this version apparently doesn’t span the full width and is anchored to the menu button

This is the point, yes. The menu elements (excluding navigation) formerly spanned one single column (constituting a list), and were anchored to the toolbar, whereas now they are spread out along additional rows and columns, anchored to the bottom as a tray.

---

@petru, implementing the menu style showcased on this ticket in mainline Fenix would resolve a majority of those user complaints. I can open a specific bug for that and attempt to port this code to Fenix as a proof-of-concept, if that would help illustrate the need for this particular UX over the status quo.

Comment 13

[Petru-Mugurel Lingurar [:petru]]

Attachment: Bug 2074348 - part 4 - Clean up legacy menu support in Focus r?#android-reviewers

Remove obsolete menu styles, width overrides, and fact-based telemetry.
Replace legacy menu resource references with Focus-owned resources and
remove Focus's direct browser-menu dependency.

Expose browser-menu through feature-customtabs because its public API
still references BrowserMenuBuilder.

Share WebCompat reporter icon loading between both Compose menus and
add coverage for delayed reporter startup in custom tabs.

Comment 14

[Petru-Mugurel Lingurar [:petru]]

Attachment: Bug 2074348 - part 8 - Show an attribution in the menu r?#android-reviewers

Added support for menu integrators configuring the menu to show attribution text
at the top or bottom of the menu, like "Powered by ..", text which is more
helpful for custom tabs menus.

Comment 15

[Sören Hentzschel]

Please do not mark this post as advocacy or off-topic, I am communicating specific design feedback directly to the developer.

Nobody has done that (so far). But again: this is off-topic. Bugzilla is not the place for general discussions like this. And more importantly, this is about Focus, not Firefox. Even if Bugzilla were the right place for such a discussion, this would be completely the wrong ticket for it.

Please stay on topic. Other people (including me, which is why I'm bringing this up) receive an email for every comment. If I want to stay up to date on the implementation of a Focus feature, having to receive emails about general discussions concerning an entirely different product is annoying.

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/7d1b5c89dd2c
https://hg.mozilla.org/integration/autoland/rev/8b0e19ff55bf
part 1 - Show the Compose menu while browsing r=android-reviewers,mcarare
https://github.com/mozilla-firefox/firefox/commit/83e750d8b95b
https://hg.mozilla.org/integration/autoland/rev/b045e01a13ca
part 2 - Show the Compose menu on the home screen r=android-reviewers,mcarare
https://github.com/mozilla-firefox/firefox/commit/ce354937b6b4
https://hg.mozilla.org/integration/autoland/rev/4d2a2170df76
part 3 - Show the Compose menu in custom tabs r=android-reviewers,mcarare
https://github.com/mozilla-firefox/firefox/commit/e3edf555f59a
https://hg.mozilla.org/integration/autoland/rev/350496f3332c
part 4 - Clean up legacy menu support in Focus r=android-reviewers,android-l10n-reviewers,parker,mcarare
https://github.com/mozilla-firefox/firefox/commit/e169834f4b00
https://hg.mozilla.org/integration/autoland/rev/bb98004af8be
part 5 - Move BrowserMenuController into MenuMiddleware r=android-reviewers,mcarare
https://github.com/mozilla-firefox/firefox/commit/fc3bdc566b8f
https://hg.mozilla.org/integration/autoland/rev/5a7b34bb963a
part 6 - Let the sticky menu group fill the width of the menu r=android-reviewers,mcarare
https://github.com/mozilla-firefox/firefox/commit/854693143e4e
https://hg.mozilla.org/integration/autoland/rev/2635052ab935
part 7 - Simplify the Compose menu layout r=android-reviewers,mcarare
https://github.com/mozilla-firefox/firefox/commit/ba98888236be
https://hg.mozilla.org/integration/autoland/rev/fd5a5f48c26a
part 8 - Show an attribution in the menu r=android-reviewers,mcarare

Comment 17

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/8b0e19ff55bf
https://hg.mozilla.org/mozilla-central/rev/b045e01a13ca
https://hg.mozilla.org/mozilla-central/rev/4d2a2170df76
https://hg.mozilla.org/mozilla-central/rev/350496f3332c
https://hg.mozilla.org/mozilla-central/rev/bb98004af8be
https://hg.mozilla.org/mozilla-central/rev/5a7b34bb963a
https://hg.mozilla.org/mozilla-central/rev/2635052ab935
https://hg.mozilla.org/mozilla-central/rev/fd5a5f48c26a

Comment 18

[Petru-Mugurel Lingurar [:petru]]

@QA Please help validate that the same menu options are shown, in the same order and they function exactly as before.

Comment 19

[Mira Lobontiu (Android QA)]

Attachment: FocusMenu.jpg

Verified on the Focus for Android Nightly 160.0a1 from 10/13 using an Oppo Find N2 Flip (Android 15), and a Huawei Pura 70 (Android 12),
All the options function as expected, verified on both light and dark theme.

Filed Bug 2081270 for a Huawei specific issue.