878551 - The list-all-tabs widget is missing an icon and misbehaves when moved

Status: RESOLVED FIXED

(Firefox :: Toolbars and Customization, defect)

Description

[u428464]

When you move the new tab button or the list all tabs arrow out of the tab strip, they show no icons or the full set. We should either prevent moving these items or add icons when they are elsewhere than the tab strip.

Comment 1

[Jared Wein [:jaws] (please needinfo? me)]

Taking this for M7 because users may think their browser is broken after merging to m-c.

Comment 2

[Mike Conley (:mconley) (:⚙️)]

Removing the items from M7 that do not block landing on m-c.

Comment 3

[:Gijs (he/him)]

Is this fixed now that bug 875488 ( https://hg.mozilla.org/projects/ux/rev/1010d94e216b ) landed?

Comment 4

[u428464]

The new tab button is fixed indeed, but the list all tabs arrow is still pretty pixelated (even if now it has an icon).

Comment 5

[u428464]

Two things : first the icon isn't looking good. Secondly I've encountered a bug when I've placed it into the navbar.

Comment 6

[:Gijs (he/him)]

(In reply to Guillaume C. [:ge3k0s] from comment #5)
> Secondly I've encountered a bug when I've placed it into the navbar.

What is the bug? What is broken? Without any further detail or STR or a screenshot or platform information, this doesn't tell us very much.

I've tried reproducing it on retina OS X, and there seems to be a rendering problem with the dropdown menu (grey bar on the right side of the menu rather than a scrollbar), but otherwise it's fine. I am unsure if this rendering problem is actually our fault.

Anyway, for one, I wouldn't call that 'broken' (I can still select tabs from the dropdown, and this seems to work fine) - but worse, I am not sure if this is the same issue you're talking about or if you're seeing something else (worse?).

Comment 7

[u428464]

Sorry I didn't have the time to be more precise at the time, but now it seems to be working fine, except that the arrow button doesn't have the right form in the nav bar (it appears like some long-ish widget). The problem I can't reproduce was much worse : the whole customization window was broken. If I can reproduce later I will post here.

Comment 8

[u428464]

Ah I may have found something :

1. Move the list all tabs button around
2. Restore default
3. Weird behaviour happens (either the list all tabs and new tab button disappear into the air or the new tab button is placed on the right)

Comment 9

[:Gijs (he/him)]

It seems like there used to be an icon in Toolbar.png (at least on Mac) for when the button wasn't in the tabstoolbar, and now there isn't.

Stephen, could you add this to the sprite?

(In reply to Guillaume C. [:ge3k0s] from comment #8)
> Ah I may have found something :
> 
> 1. Move the list all tabs button around
> 2. Restore default
> 3. Weird behaviour happens (either the list all tabs and new tab button
> disappear into the air or the new tab button is placed on the right)

Can you file a new bug for this with the OS information and these steps to reproduce? Thanks! :-)

Comment 10

[u428464]

I will investigate a bit more because I can't find precise steps to reproduce and the problem appears randomly.

Comment 11

[Justin Dolske [:Dolske]]

Summary is extremely confusing. I see two issues in a current UX build, fresh profile:

* Moving this widget to the navbar gives it a tiny scaled version of Toolbar.png (like a horizontal line).

* Moving it back to the tab strip make it misbehave. It disappears, but sometimes flickers into view when opening/closing a tab.

Reset Defaults seems to clear things up, though.

Perhaps the simple fix is to just make it non-removable from the tab strip?

P2 because this seems like an unlikely customization that is fixable.

Comment 12

[Stephen Horlander [:shorlander]]

(In reply to Justin Dolske [:Dolske] from comment #11)
> Perhaps the simple fix is to just make it non-removable from the tab strip?

This makes the most sense when viewing the tabstrip design as a whole. It is also pretty strange to have these buttons change shape/behavior when moving them to new locations; i.e. less magic button behavior. We should make the new tab and tab overflow list non-removable.

If we think that it's still useful to have new tab and tab list toolbar buttons we should add those to the tools customization separately.

Comment 13

[:Gijs (he/him)]

Note to self/whoever fixes this: making them non-removable might not be enough in terms of migrating users who already have them elsewhere, as buildArea doesn't check whether widgets are removable from their original area before adding them somewhere else, so that would need to be fixed, too (it needs to be fixed anyway, I suppose...). See also bug 886323.

Comment 14

[:Gijs (he/him)]

Attachment: The list-all-tabs button should always be in the tabbar,

Trivial patch now that bug 886323 is fixed.

Comment 15

[:Gijs (he/him)]

https://hg.mozilla.org/projects/ux/rev/c75d16df268d

Comment 16

[:Gijs (he/him)]

https://hg.mozilla.org/mozilla-central/rev/c75d16df268d

Comment 17

[Oriol Brufau [:Oriol]]

So it seems the problem was that the "list all tabs" didn't behave properly when moved into the navbar.
Then I understand that you want to prevent it from being moved into the navbar.
But I think it should still be possible for users to remove it.
I don't want it, it takes space, I usually misclick it, and then it freezes the browser for various seconds because it's so slow when you have lots of tabs.

Comment 18

[:Gijs (he/him)]

(In reply to Oriol Brufau [:Oriol] from comment #17)

But I think it should still be possible for users to remove it.

There's no infrastructure in CustomizableUI right now that would allow something like this (ie allow removal but not moving elsewhere). We'd have to do something custom, plus we'd need an icon for customize mode (or we'd have to then show it in the tabstrip again, but use a custom checkbox along the lines of the download button or something).

I don't want it, it takes space, I usually misclick it,

If these misclicks are a really big problem for you right now, I'd use userChrome.css to hide it.

I don't think we want to allow users hiding it generally, when it's the only way for people to find tabs back if hidden by a malicious extension.

and then it freezes the browser for various seconds because it's so slow when you have lots of tabs.

I'd rather fix this. bug 1384733 . It's on my list along with bug 1634051.