[customizable-menu] Show the extensions menu item in browser screen's menu
Categories
(Firefox for Android :: Menu, task)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox159 | --- | fixed |
People
(Reporter: petru, Assigned: petru)
References
(Depends on 2 open bugs, Blocks 1 open bug)
Details
(Whiteboard: [fxdroid][android-core])
Attachments
(2 external files, 1 obsolete file)
Needed:
- a
BrowserMenuBuilderthat has a hardcoded structure of thedefaulthome menu - this is instantiated by the
MenuStores middleware and queried for the menu configuration to use - the configuration is updated by the
MenuStores middleware to be displayed - the
MenuStores middleware will handle the menu item interactions
*Note: This needs also configuring all the extensions to be displayed, everything that would be shown when it is clicked to be expanded.
Updated•2 months ago
|
| Assignee | ||
Updated•2 months ago
|
| Assignee | ||
Comment 1•2 months ago
|
||
| Assignee | ||
Comment 2•2 months ago
|
||
WebExtensionMenuActions.kt is now the one place that maps BrowserState to what actions do installed
extensions offer for the current tab:
- WebExtensionMenuAction - allows passing all details inside menu items and events.
- Flow<BrowserState>.webExtensionMenuActions combines the browser-level and tab-level flows to get
what extensions actions are available for the current tab. Icons are only loaded when the
extensions or their tab state actually change. - BrowserState.findWebExtensionMenuAction resolves the same action again at click time.
ExtensionsMenuItemProvider now lists what actions are offered by installed extensions for the
current tab rather than the installed addons:
WebExtensionsMenuBinding now consumes the shared flow too — it drops to a thin mapping onto its
lambda-carrying WebExtensionMenuItem, so the two menus can't drift apart. Its existing tests
exercise the shared code unchanged.
Two deliberate differences from the old menu:
- The per-row settings button only appears when the action belongs to an addon the user installed.
The old menu always drew it and did nothing when there was no matching addon. - The click resolves the action at click time rather than capturing it when the menu was built, so
an extension that changed in the meantime no longer runs a stale action.
Updated•2 months ago
|
Updated•2 months ago
|
| Assignee | ||
Comment 3•2 months ago
|
||
WebExtensionMenuActions.kt is now the one place that maps BrowserState to what actions do installed
extensions offer for the current tab:
- WebExtensionMenuAction - allows passing all details inside menu items and events.
- Flow<BrowserState>.webExtensionMenuActions combines the browser-level and tab-level flows to get
what extensions actions are available for the current tab. Icons are only loaded when the
extensions or their tab state actually change. - BrowserState.findWebExtensionMenuAction resolves the same action again at click time.
ExtensionsMenuItemProvider now lists what actions are offered by installed extensions for the
current tab rather than the installed addons:
WebExtensionsMenuBinding now consumes the shared flow too — it drops to a thin mapping onto its
lambda-carrying WebExtensionMenuItem, so the two menus can't drift apart. Its existing tests
exercise the shared code unchanged.
Two deliberate differences from the old menu:
- The per-row settings button only appears when the action belongs to an addon the user installed.
The old menu always drew it and did nothing when there was no matching addon. - The click resolves the action at click time rather than capturing it when the menu was built, so
an extension that changed in the meantime no longer runs a stale action.
Updated•2 months ago
|
Comment 5•1 month ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/13a5231ea002
https://hg.mozilla.org/mozilla-central/rev/fcccf0097201
Description
•