1944719 - Sidebar extensions should be unpinnable from the launcher

Status: VERIFIED FIXED

(Firefox :: Sidebar, enhancement, P1)

Description

[Ania]

As a user of sidebar-capable extensions, I want to have more control over managing them.

Acceptance criteria

1. I can right-click any of my installed sidebar-capable extensions in the sidebar, and access the context menu with the following options:

- Manage Extension (link)
Clicking Manage Extension opens its page in about:addons.
Toggling the extension off in its page in about:addons removes it from the sidebar.

- Remove Extension (link)
Opens a confirmation dialog (as when a user removes an extension from a toolbar).

- Report Extension (link)
Clicking Report Extension opens an add-on report form in a new tab https://addons.mozilla.org/en-US/firefox/feedback/addon/%addonid%.

- Remove from Sidebar (separated from options above by a separator)
On click, the extension favicon is removed from sidebar, but remains installed in Firefox. No confirmation dialog is displayed.
If the extension is removed from the sidebar, it is still displayed in the Customize sidebar > Extensions menu, with an unchecked checkbox next to it.

2. If I have sidebar-capable extensions installed, I can see them displayed as a checkbox list in the Customize sidebar > Extensions menu

• Unchecking a checkbox removes the extension from the sidebar, keeping it installed and enabled.
• Unchecking the checkbox again returns the extension’s icon to the sidebar Tools area.
• Upon clicking any sidebar-capable extensions in the Customize sidebar menu, the extension page in about:addons opens in a new tab, and the sidebar remains open.

3. If I do not have any sidebar-capable extensions installed, the Extensions card in the Customize sidebar menu is not displayed.

Please note that we descoped showing users a link to the AMO for now, since we don't yet have a sidebar-ready collection of extensions created. We might return to it in the future, in another ticket.

Comment 1

[Ania]

Attachment: Customize sidebar checkboxes.png

Comment 2

[Ania]

Attachment: Right click menu

Comment 5

[Sarah Clements [:sclements]]

One update, per the April 24th discussion in slack the "Browse extensions" link will be replaced with "Manage extensions" in the Customize Sidebar panel (per the "Customize sidebar checkboxes.png" attached to this bug) since we'll be removing each extensions link to their respective about:addons page.

Comment 6

[Sarah Clements [:sclements]]

Attachment: Bug 1944719 - Make sidebar extensions removeable from launcher r=#sidebar-reviewers,robwu

Comment 7

[Rob Wu [:robwu]]

(I wrote this comment before the patch was uploaded, but I have to do something else now, so I'll post the comment and check the patch later if needed).

Sarah asked the following question:

I'm hitting a tricky issue with sidebar extensions... for this bug, we want to make sidebar extensions unpinnable from the sidebar launcher. That means adding it to the sidebar.main.tools pref that stores what tools a user has selected (bookmarks, history, etc) in the Customize Sidebar panel. As part of making sidebar extensions unpinnable, there was an ask to have any that were previously installed in a prior release to be selected by default until they are deselected by the user. This would normally mean we'd do a one-time migration to add the name of those sidebar extensions to sidebar.main.tools or possibly do that in SidebarManager, but the timing for when we know about all extensions is not clear to me. Is there anyway to access them in either this file? Is there a notification that SidebarManager can observe to say "these are all that are installed on startup"? I don't see anything in ext-sidebarAction for that specifically.

I'll first answer your question, and then suggest a potentially different way of looking at it.

To query the full set of add-ons that could possibly have a sidebar, use AddonManager.getActiveAddons(["extension"]) (without the parameter, you could also get a theme among the results).

Next step is to determine which of those have a sidebar. At startup, it is possible for the extension to still be starting, and to not have reached the relevant logic that initializes the sidebar if needed, in onManifestEntry in ext-sidebarAction.js. Once that point is reached, and onReady is called, I expect SidebarController to already know about sidebars, if any.

I don't know what you exactly want to do, so here is an example to look up all sidebar extensions:

const { addons } = await AddonManager.getActiveAddons(["extension"]);
const addonIds = addons.map(addon => addon.id);
for (const id of addonIds) {
  let policy = WebExtensionPolicy.getByID(id);
  if (!policy) {
    // TODO: Extension not started yet, handle later.
    // You can listen to ExtensionParent.apiManager.on("ready", listener);
    // ... which receives (name, extension), and use extension.id to see if it is in the list.
    // If you've seen the whole list, you're done.
    // TODO: also handle cases where the extension was disabled or failed to start in the meantime.
    // Alternative to waiting is to parse the extension package and query information (which is expensive), see
    // https://searchfox.org/mozilla-central/rev/99f02d7a9456d4cfe2abd9c2a4a1eb8f3f41e22a/toolkit/mozapps/extensions/internal/XPIInstall.sys.mjs#451-471
    continue;
  }
  if (policy.readyPromise) {
    // Still starting, wait for it to be a bit more ready (past loading the manifest)
    await policy.readyPromise;
  }
  if (policy.extension?.manifest?.sidebar_action) {
    // TODO: This is a sidebar extension, now what?
    // TODO: Do we care about all sidebar extensions, or only those that are shown by default?
  }
}

.... now, the above logic matches what you were asking for, but I don't think that it's the best way to do this.

Instead of getting the information upfront, would it be feasible to assume that is was already installed, and mark as new install otherwise? E.g. when you detect a new extension installation (or are about to register the sidebar in ext-sidebarAction.js, check if extension.startupReason === "ADDON_INSTALL", and if so, do something special about it)?

Comment 8

[Sarah Clements [:sclements]]

(In reply to Rob Wu [:robwu] from comment #7)

Instead of getting the information upfront, would it be feasible to assume that is was already installed, and mark as new install otherwise? E.g. when you detect a new extension installation (or are about to register the sidebar in ext-sidebarAction.js, check if extension.startupReason === "ADDON_INSTALL", and if so, do something special about it)?

I don't think checking for this in SidebarController.registerExtension would help specifically with knowing how many sidebar extensions are enabled because of how onManifestEntry is called, which seems to be based on a for loop of window listeners with no sort of resolved promise or notification to suggest "this is all of them". Calling a handler in SidebarController.Init in requestIdleCallback seems to work for the pref migration as it allow for all of the sidebar extensions to be registered then added to the sidebar.main.tools pref. Though I don't know if there could be some scenerio where this is a bit racey..

Comment 9

[Ania]

Attachment: extension_context_menu.png

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/5a46b671f5af
https://hg.mozilla.org/integration/autoland/rev/a3b948ae1425
Make sidebar extensions removeable from launcher r=sidebar-reviewers,kcochrane,robwu

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/fc88446a793b
https://hg.mozilla.org/integration/autoland/rev/83622f10cc76
Revert "Bug 1944719 - Make sidebar extensions removeable from launcher r=sidebar-reviewers,kcochrane,robwu" for causing xpcshell failures at test_shutdown_barriers.js

Comment 13

[Cristina Horotan [:chorotan]]

Backed out for causing xpcshell failures on test_shutdown_barriers.js

Backout link

Push with failures

Failure log

Comment 14

[Rob Wu [:robwu]]

Since test_shutdown_barriers.js is a test in extensions code, I took a closer look.

The failure is triggered because test_shutdown_barriers.js enters a shutdown phase, which triggers a promise rejection via a shutdown blocker in SharedDataMap.sys.mjs:

INFO - "CONSOLE_MESSAGE: (error) [JavaScript Error: "uncaught exception: undefined" {file: "resource://nimbus/lib/SharedDataMap.sys.mjs" line: 226}]"
WARNING - TEST-UNEXPECTED-FAIL | xpcshell.toml:toolkit/mozapps/extensions/test/xpcshell/test_shutdown_barriers.js | test_late_bootstrapscope_startup_rejected - [test_late_bootstrapscope_startup_rejected : 266] A promise chain failed to handle a rejection: undefined - stack: _checkIfShutdownStarted@resource://nimbus/lib/SharedDataMap.sys.mjs:226:27
INFO - SharedDataMap/this._shutdownBlocker@resource://nimbus/lib/SharedDataMap.sys.mjs:28:14
INFO - trigger@resource://gre/modules/AsyncShutdown.sys.mjs:754:23
INFO - _wait@resource://gre/modules/AsyncShutdown.sys.mjs:914:15
INFO - wait@resource://gre/modules/AsyncShutdown.sys.mjs:895:34
INFO - observe@resource://gre/modules/AsyncShutdown.sys.mjs:554:10
INFO - test_late_bootstrapscope_startup_rejected@/builds/worker/workspace/build/tests/xpcshell/tests/toolkit/mozapps/extensions/test/xpcshell/test_shutdown_barriers.js:223:20

In the patch that was pushed to autoland, ext-sidebarAction.js unconditionally loads SidebarManager.sys.mjs, which is used as a module with utilities, but is not side-effect free. It loads Nimbus, and ultimately a subclass of SharedDataMap that will trigger the error.

One thought to reduce the overhead is to make SidebarManager.sys.mjs lazily loaded in ext-sidebarAction.js. This will reduce the startup cost of the ext-sidebarAction.js module. This module is currently loaded in the test because any attempt to uninstall an extension triggers onUninstall in ext-sidebarAction.js.

To reduce the frequency of triggering the loading of SidebarManager.sys.mjs when not needed, I also suggest checking whether the extension ID is listed in sidebar.installed.extensions before trying to load the module.

There are also other alternatives, such as making SidebarManager.sys.mjs side effect free, or putting the utilities in a new class (or even directly in ext-sidebarAction.js).

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/a5ae1360a22e
https://hg.mozilla.org/integration/autoland/rev/93456979c392
Make sidebar extensions removeable from launcher r=sidebar-reviewers,kcochrane,robwu

Comment 16

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/93456979c392

Comment 17

[Ania]

Release Note Request
[Why is this notable]: Highly requested enhancement.
[Affects Firefox for Android]: No
[Suggested wording]: You can now remove extensions from the sidebar. Right-click the extension icon and select Remove from Sidebar.
[Links (documentation, blog post, etc)]:

Comment 18

[Rob Wu [:robwu]]

(In reply to Ania from comment #17)

[Suggested wording]: You can now remove extensions from the sidebar. Right-click the extension icon and select Remove from Sidebar.

Is this phrasing sufficiently clear? "The extension icon" implies that there is only one obvious option. But extension icons/buttons are also visible on the toolbar when they are pinned, as documented at https://support.mozilla.org/en-US/kb/extensions-button

An example of a less ambiguous wording would be:
"extension icon" -> "extension icon on the sidebar"

Also: There is a "Remove extension" menu item on the extension button, which uninstalls an extension once chosen. The current proposed text states "remove extensions", which sounds similar. Would "hide extensions [from the sidebar]" be a better phrase here?

Comment 19

[Sarah Clements [:sclements]]

Attachment: Bug 1944719 - Make sidebar extensions removeable from launcher r=#sidebar-reviewers,robwu

Original Revision: https://phabricator.services.mozilla.com/D249433

Comment 20

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined: Less ideal experience with the sidebar for extension users
• Code covered by automated testing: yes
• Fix verified in Nightly: no
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: Sidebar extensions can now be removed from the sidebar launcher per the spec in the bug. If an extension is removed or disabled, it will also be removed from the launcher. If an extension is re-added, the tool is added back to the launcher automatically; if it's re-enabled it will remember whatever any user actions. The users preference with regards to installed extensions should be remembered between sessions the same way other tools like bookmarks and history are.
• Risk associated with taking this patch: Medium
• Explanation of risk level: It adds a new capability with changes in sidebar modules and extension code specifically for extensions with a sidebar.
• String changes made/needed: No
• Is Android affected?: no

Comment 21

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/1a54b1c79008
https://hg.mozilla.org/releases/mozilla-beta/rev/d2e5b6afa6ec

Comment 22

[Dianna Smith [:diannaS]]

Added to the 142 beta release notes https://www.mozilla.org/en-US/firefox/142.0beta/releasenotes/

Comment 23

[Ina Popescu, Desktop QA]

I've tested this enhancement so far on Windows 10 and macOS 15 using the latest Nightly 143.0a1 (2025-07-31) and Firefox 142.0b5 and noticed several issues.

Issues observed while following the Acceptance Criteria
Some menu items don’t match the expected capitalization from the extension_context_menu.png reference. screenshot.
Not all expected options ("Remove from Sidebar") are shown in Beta. screenshot.
The "Manage Extensions" link is missing from the Customize Sidebar panel in Beta. screenshot.

In Nightly, clicking an extension name in the Customize sidebar > Sidebar extensions menu does not open about:addons (it works in Beta where they are hyperlinked). video.
In Beta, the checkboxes to show/hide sidebar extensions are missing.screenshot.

Other issues
When an extension icon is missing, there’s no default icon shown. video.
The separator in the context menu is hard to see at default sidebar width; it becomes visible when the sidebar is narrower. video.

After restarting Firefox, the order of unchecked extensions in the sidebar changes. video.
Extensions are added to the bottom of the list during normal use, but added to the top in Safe Mode. video.

Should these be filed as separate issues?

Comment 24

[Ina Popescu, Desktop QA]

@Ania, just wanted to check in on the test results I added above. Should I file any additional issues? Thank you!

Comment 25

[Sarah Clements [:sclements]]

(In reply to Ina Popescu, Desktop QA from comment #23)

I've tested this enhancement so far on Windows 10 and macOS 15 using the latest Nightly 143.0a1 (2025-07-31) and Firefox 142.0b5 and noticed several issues.

Hi, I missed your initial comment in my bug mail - next time please request information from the person assigned to the bug so your questions can be addressed promptly! (Also Ania is a product manager and does not regularly monitor bug mail.)

Issues observed while following the Acceptance Criteria
Some menu items don’t match the expected capitalization from the extension_context_menu.png reference. screenshot.

None of those strings were changed in this patch except "Remove from Sidebar" which is correct. I don't think we need a bug for changing capitalization of the other items.

Not all expected options ("Remove from Sidebar") are shown in Beta. screenshot.
The "Manage Extensions" link is missing from the Customize Sidebar panel in Beta. screenshot.

In Nightly, clicking an extension name in the Customize sidebar > Sidebar extensions menu does not open about:addons (it works in Beta where they are hyperlinked). video.

Extension names are not supposed to open a link to that extension - they're supposed to behave the same as the other Firefox tools (that's why there's now a separate link to manage extensions).

In Beta, the checkboxes to show/hide sidebar extensions are missing.screenshot.

Looking at 142.0b9 I'm seeing the correct behavior with menus and checkboxes. Your screenshots indicate you were looking at a beta build that didn't include this patch. Can you confirm please?

Other issues
When an extension icon is missing, there’s no default icon shown. video.

That's an existing issue that I also noticed while working on this, but it's unrelated to the changes in this patch. Please file a separate bug as I had forgotten to do so.

The separator in the context menu is hard to see at default sidebar width; it becomes visible when the sidebar is narrower. video.

That video shows you resizing the launcher, which looks unrelated to these changes?

After restarting Firefox, the order of unchecked extensions in the sidebar changes. video.
Extensions are added to the bottom of the list during normal use, but added to the top in Safe Mode. video.

Issues with tool order not persisting are pre-existing, see bug 1915440.

Comment 26

[Ina Popescu, Desktop QA]

Thanks for the clarification. I’ve retested in Firefox 142.0b9 and the “Remove from Sidebar” option, “Manage Extensions” link, and checkboxes are all present. I’ve also filed Bug 1982519 for the missing default icon when an extension has no icon.
Verification completed on macOS 15, Windows 10 and Ubuntu 22.04 and marking this enhancement as Verified Fixed.