1929599 - Extension widgets in the TabsToolbar are moved to the overflowed-extensions-list when vertical tabs are enabled.

Status: NEW

(Firefox :: Sidebar, enhancement, P3)

Description

[Nikki Sharpley (:nikkis) (she/her)]

This is expected behaviour. However, its not intuitive as to where he extension widget has been moved and its not possible to move the extension widget out of the overflow to the nav-bar. We should look into whether supporting this customization is possible.

Comment 1

[William Durand [:willdurand]]

its not possible to move the extension widget out of the overflow to the nav-bar

Users can unpin the extension from that list in the panel, then the extension lives in the panel, and therefore it can be pinned to the nav-bar. There is a lot of room for improvement when it comes to the extensions panel and the CUI palette (which UX is looking into).

Comment 2

[Ania]

Stuart has tested this behavior on 128.4.0esr and ran it with a fresh profile with tab stats add-on installed.

Here are Stuart's notes:
After installation the add-on is alongside the tabs. However, if you uncheck “pin to toolbar” and recheck it, the add-on is not put back in tabstrip; instead it ends up in the toolbar. Similarly if you uninstall the add-on and re-install it having made the previous changes it is put back into the same toolbar location (not alongside the tabstrip).

This suggests to us it is the current add-ons behaviour and not introduced by any of our changes.

Will, are you comfortable moving this bug into the Add-ons team component?

This is my crude approximation of expected behavior for add-ons that define their default location in the tab-strip:

• upon switching to vertical tabs - add-on is placed into the toolbar,
• upon switching from vertical to horizontal tabs - add-on is place into the tab-strip.
• upon unpinning the extension - add-on is placed into the extensions overflow menu. The string change might be needed here, too (Unpin/Pin from/to toolbar - > Unpin/Pin to navbar)
• upon reinstallation - add-on is placed into the tab-strip.

Nicole, I think your team should define expected behavior and priority here, so tagging you as above is just my informal expectation.

Comment 3

[Nicole Weber [:topotropic]]

Thanks for the ping, Ania. Let me also put it on Alan's radar.

Will, what browser chrome destinations can an extension define? I assumed it was only the toolbar and not other places like the tab strip. You think we could limit the destination to toolbar, it might make it more predictable to work with for users and also us.
I also ran into the issue where I reinstalled an extension and it remembered my decision to unpin it which I found a little odd, I think de-install and re-install is a sufficient signal to reset everything and not remember the placement.
Curious to get your thoughts.

Comment 4

[William Durand [:willdurand]]

(In reply to Ania from comment #2)

This suggests to us it is the current add-ons behaviour and not introduced by any of our changes

I don't think so. This bug is tied to vertical tabs because of how we overflow the extension widgets in the panel when we enable vertical tabs. In fact, I am not entirely sure how we came up to this behavior in the first place since I thought we wanted to pin all widgets (including extensions) to the nav-bar when switching to vertical tabs.

What isn't ideal here, though, is how many steps it requires to put the extension back into a toolbar (be it the nav-bar or tabstrip if vertical tabs are disabled). That's what I was thinking about in Comment 1.

That being said, in Stuart's notes, I think we have two other bugs worth filing:

After installation the add-on is alongside the tabs. However, if you uncheck “pin to toolbar” and recheck it, the add-on is not put back in tabstrip; instead it ends up in the toolbar.

"Pin to toolbar" currently unconditionally puts the extension into the nav-bar. That said, this menu item is checked when the extension is in the tabstrip because the tabstrip is a toolbar. We use "toolbar" to mean "not the menupanel (i.e. the extensions panel). Per https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/browser_action, extensions can attempt to be placed in 3 toolbars by default: navbar, tabstrip, personaltoolbar. If this isn't possible, we default to the nav-bar or the panel (at the last resort).

So this could be a new bug, though I am not sure how we'd resolve this.

Similarly if you uninstall the add-on and re-install it having made the previous changes it is put back into the same toolbar location (not alongside the tabstrip).

This is an existing behavior that is documented but I am not sure why we have this one and it'd be good to file a bug to discuss. I feel like removing an extension should clear its placement so that we can get back to the default placement upon re-installation. That would help with reproducibility too.

Will, are you comfortable moving this bug into the Add-ons team component?

As mentioned above, this bug is more a "vertical tabs" bug than an add-ons bug.

This is my crude approximation of expected behavior for add-ons that define their default location in the tab-strip:

• upon switching to vertical tabs - add-on is placed into the toolbar,
• upon switching from vertical to horizontal tabs - add-on is place into the tab-strip.

Yep, and that isn't what's happening today. Currently, upon switching to vertical tabs, the extensions are overflowed in the panel, and this was introduced in Bug 1899346.

• upon unpinning the extension - add-on is placed into the extensions overflow menu. The string change might be needed here, too (Unpin/Pin from/to toolbar - > Unpin/Pin to navbar)

We could potentially update the string indeed, though it wouldn't be trivial as described above.

• upon reinstallation - add-on is placed into the tab-strip.

I kinda agree, yeah. Let's file a different bug for that.

(In reply to Nicole Weber [:topotropic] from comment #3)

Will, what browser chrome destinations can an extension define? I assumed it was only the toolbar and not other places like the tab strip. You think we could limit the destination to toolbar, it might make it more predictable to work with for users and also us.

Per https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/browser_action, extensions can attempt to be placed in 4 areas by default: navbar, tabstrip, personaltoolbar (bookmarks/personal toolbar - this one is hard to describe since it has a different name depending on who you talk to...), and menupanel (the extensions panel).

I also ran into the issue where I reinstalled an extension and it remembered my decision to unpin it which I found a little odd, I think de-install and re-install is a sufficient signal to reset everything and not remember the placement.

Agreed.

Comment 5

[Stuart Colville [:muffinresearch]]

I think there's some conflation between the specifics of this bug (what happens to extensions with a default area: tabstrip and the use of vertical tabs) and the additional behaviours encountered looking into that.

To clarify, the testing done on ESR was intended to only clarify the additional behaviours encountered that seemed potentially confusing and to make sure they weren't related to vertical tabs changes. The behaviour specific to this bug can't be tested on ESR because of the lack of vertical tabs.

How we ended up with the current behaviour was based on the understanding that the default_area is seen as more of a hint where to put something at install (rather than a guarantee) and putting the extension in to the extension menupanel when the current location is not available is how it currently works for other cases (e.g. the visibility of the personaltoolbar (aka bookmarks toolbar) is variable) so the status quo is consistent with that. This is because the vertical tabs tabstrip doesn't currently support the tab_strip location (hence this bug).

However, I think the key points of contention to focus on in this bug specifically are as follows:

1. If you switch from horizontal tabs (with an extension installed to the tabstrip - and without having customized its location) to vertical tabs the extension moves location from the tab strip to the extension menupanel (which could be viewed as the extension disappeared). Note: If you switch back (and haven't customized the location in the meantime) it will still be in the horizontal tab-strip when horizontal tabs are re-enabled.
2. It's potentially confusing that an extension will do one thing for a horizontal tab installation and something else when vertical tabs are enabled.

The current workaround for 1) is to customize the location of the extension. If the extension is moved to the navbar that will be visible in both horizontal and vertical tab configurations. The easiest way to do this when using vertical tabs is to find the extension in the extension menu and uncheck/recheck "pin to toolbar" from the cog menu. Alternatively in horizontal tabs mode, you can use customize mode, and drag the extension to the navbar.

Would be good to clarify what consistency between tab modes should look like, and of course, if there's any possibility that tab_strip default locations might be deprecated in the future for other reasons, it would be good to decide that first to avoid unnecessary changes.