1405200 - new tab button is missing

Status: RESOLVED DUPLICATE of bug 1370791

(Firefox :: Tabbed Browser, defect, P2)

Description

[Karl Tomlinson (:karlt)]

Attachment: new tab button is missing

The bug reproduces with

user_pref("browser.uiCustomization.state", "{\"placements\":{\"widget-overflow-fixed-list\":[],\"PersonalToolbar\":[\"personal-bookmarks\"],\"nav-bar\":[\"back-button\",\"forward-button\",\"stop-reload-button\",\"unified-back-forward-button\",\"konquefox_erase-button\",\"urlbar-container\",\"downloads-button\",\"reload-button\",\"stop-button\",\"window-controls\",\"webrtc-status-button\",\"loop-button\",\"screenshots_mozilla_org-browser-action\"],\"TabsToolbar\":[\"appmenu-toolbar-button\",\"tabbrowser-tabs\",\"tabmixScrollBox\",\"new-tab-button\",\"alltabs-button\",\"tabmix-tabs-closebutton\"],\"toolbar-menubar\":[\"menubar-items\",\"zoom-controls\",\"konquefox_erasesearchbar-button\",\"search-container\"],\"addon-bar\":[\"addonbar-closebutton\",\"customizableui-special-spring1\",\"status-bar\"]},\"seen\":[\"loop-button\",\"pocket-button\",\"developer-button\",\"webide-button\",\"screenshots_mozilla_org-browser-action\"],\"dirtyAreaCache\":[\"addon-bar\",\"PersonalToolbar\",\"nav-bar\",\"TabsToolbar\",\"toolbar-menubar\",\"PanelUI-contents\"],\"currentVersion\":12,\"newElementCount\":29}");

and no longer reproduces when '\"tabmixScrollBox\",' is removed.
I assume that is left over from the Tab Mix Plus add-on.

Comment 1

[Karl Tomlinson (:karlt)]

Attachment: The new tab button is configured to be positioned on the right of tabs

Removing and replacing the button does not restore it.
Placing the button on the left of the tabs makes it visible.
Moving it back to the right makes it invisible/missing.

Comment 2

[Karl Tomlinson (:karlt)]

Attachment: The button shows once the tabbar is full

(if you can find a way to add new tabs)

Comment 3

[Karl Tomlinson (:karlt)]

[Tracking Requested - why for this release]:
Lack of a new tab button is a serious usability problem.
There is no equivalent context menu item, nor hamburger menu item.

Tab Mix Plus is a reasonably popular add-on, but other add-ons also
provide toolbar items, and so the problem may be more widespread.

bug 1405202 makes this a regression in 57.

Comment 4

[Jim Mathies [:jimm]]

This looks like an issue where tab mix plus causes broken front-end ux through some sort of change it makes that never gets reverted on uninstall. There are some similar support reports out there [1].

https://support.mozilla.org/en-US/questions/1021352

Andy, thoughts? Seems like we should be doing a better job of cleanup.

Comment 5

[Andy McKay]

This sounds similar to bug 1405202 and why we are moving to WebExtensions. I've pinged the Tab Mix Plus author on this bug to see if they can clean it up.

Karlt, you haven't said which version it is, can I assume its the legacy version here? 

https://addons.mozilla.org/en-US/firefox/addon/tab-mix-plus/?src=ss

Comment 6

[Andy McKay]

I notice there's also konquefox_erase-button in there. Would it make sense to just reset browser.uiCustomization.state when people update to Firefox 57?

Comment 7

[Jim Mathies [:jimm]]

Hey Karl, is this the legacy add-on or webext version?

Comment 8

[Andy McKay]

I know what's happening here and no need to ping Yuki or Karl. I think we need to fix this in order to reset this pref. Asking gijs as my go to front end person.

Comment 10

[:Gijs (he/him)]

(In reply to Andy McKay [:andym] from comment #8)
> I know what's happening here and no need to ping Yuki or Karl. I think we
> need to fix this in order to reset this pref. Asking gijs as my go to front
> end person.

We can't just reset the pref because it will break people's custom toolbar customizations. Especially for e.g. the search bar removal, the explicit goal is to keep things as they are for people upgrading from 56, and not have a search bar anymore for new users (with an easily-accessible switch in the prefs).

This is basically a special case of bug 1370791. I would rather we fix that bug specifically.

If we can't do that, we would need to try to remove items from the toolbar that no longer exist. It's not clear where/how that would be possible, because items can be added post-restart, and webextensions start somewhat lazily now. So at what point should customizableUI basically go "oh, these tabmix plus items are dead, let's remove them"? Maybe Bob knows...

Comment 11

[Bob Silverberg [:bsilverberg]]

Sorry to pass the buck, but as this has to do with what happens at startup, I think Kris would be the best one to discuss what, if anything, WebExtensions code should do about this.

Comment 12

[Andy McKay]

This has nothing to do with WebExtensions, in that its only legacy add-ons that have had the ability to flip this pref. Its the fact that the legacy add-ons don't get uninstalled, they just leave the changes in the pref. I think in this case bug 1370791 is the best answer.

If we wanted to do more, we'd have to write some special code somewhere to examine prefs and remove known bad cases, rather like e10s-rollout does.

For the moment I'm duping to bug 1370791.

Comment 13

[Michał Gołębiowski-Owczarek [:mgol]]

(In reply to Andy McKay [:andym] from comment #12)
> This has nothing to do with WebExtensions, in that its only legacy add-ons
> that have had the ability to flip this pref. Its the fact that the legacy
> add-ons don't get uninstalled, they just leave the changes in the pref.

I may not understand all the implications but if the problem is legacy add-ons only get disabled, not uninstalled (and, as I understand, they will never get their uninstallation procedure fired as they no longer are allowed to work) could the answer for Firefox 56 -> 57 update be to simulate legacy add-on uninstallation but then re-add them to the "Legacy extensions" list without following their installation procedures? They could then be updated to a fully WebExtension versions if they get released in the future.

Comment 14

[Karl Tomlinson (:karlt)]

FWIW yes, its version 0.5.0.4 (I wonder why about:addons prevents that from
being selectable), which is legacy.

I'm not aware of a WebExtensions version.
"Find a Replacement" links to
https://addons.mozilla.org/en-US/firefox/addon/tab-center-redux/?src=find-replacement
but its blurb sounds very different.

Comment 15

[Karl Tomlinson (:karlt)]

(In reply to Michał Gołębiowski-Owczarek [:mgol] from comment #13)
> (In reply to Andy McKay [:andym] from comment #12)
> > This has nothing to do with WebExtensions, in that its only legacy add-ons
> > that have had the ability to flip this pref. Its the fact that the legacy
> > add-ons don't get uninstalled, they just leave the changes in the pref.
> 
> I may not understand all the implications but if the problem is legacy
> add-ons only get disabled, not uninstalled (and, as I understand, they will
> never get their uninstallation procedure fired as they no longer are allowed
> to work) could the answer for Firefox 56 -> 57 update be to simulate legacy
> add-on uninstallation but then re-add them to the "Legacy extensions" list
> without following their installation procedures? They could then be updated
> to a fully WebExtension versions if they get released in the future.

The "uninstall" hypothesis was an incorrect assumption on my part re bug
1405202.

The cause is similar but different: The pref is usually restored by this
add-on on clean shutdown, but remained in my testing because the last browser
run with 56 did not cleanly shut down.

Similarly, perhaps it's an option to run all disabled add-ons through a clean
shutdown, but I don't know whether that is practical or sensible.

Comment 16

[Ethan Tseng [:ethan]]

Mirror the status of bug 1370791.