1824247 - unified extensions button is greyed out in customization mode even though it's movable now

Status: NEW

(Firefox :: Toolbars and Customization, defect, P3)

Description

[Sören Hentzschel]

Attachment: screenshot.png

Since bug 1820743 the unified extensions button can be moved on the navigation toolbar. But in the customization mode the button has still an opacity and looks as it couldn't be moved due to the following rule:

toolbarpaletteitem[removable="false"] {
  opacity: 0.5;
}

So while it works as implemented (the button is not _re_movable and therefore the opacity is applied) I don't think that the opacity should be applied if it's possible to do something useful with the button, like moving within the toolbar.

Comment 1

[:Gijs (he/him)]

That rule is from before we allowed dragging removable=false items at all (you used to just drag other stuff around them). We could remove it.

I think it didn't get noticed before because the main item that's removable=false is the url bar, and greying that out made sense because it's disabled (doesn't make sense to navigate while in customize mode), so that seemed OK.

We can probably remove this rule but we'd want to make sure that the back/fwd buttons, url bar, hamburger + overflow button etc. stay greyed out. (Not sure off-hand if there are other things taking care of that or no. Looks like "no" for the address bar, at least.)

Comment 2

[Itiel]

(In reply to :Gijs (he/him) from comment #1)

I think it didn't get noticed before because the main item that's removable=false is the url bar, and greying that out made sense because it's disabled (doesn't make sense to navigate while in customize mode), so that seemed OK.

We can probably remove this rule but we'd want to make sure that the back/fwd buttons, url bar ... stay greyed out.

Not sure I understand your reasoning, AIUI buttons (or other items) should be greyed out in this context if they are not movable, not because they are uninteractionable (e.g. navigating using the address bar as you mentioned). According to your reasoning the searchbar should also be greyed out?

and greying that out made sense because it's disabled

fwiw for the literal [disabled] case we have this rule:
https://searchfox.org/mozilla-central/rev/f5dde549cca5193743d11daa1c5f08258bee9d42/browser/themes/shared/customizableui/customizeMode.css#402-406
... which, from a quick look, indeed affect only the hamburger and overflow buttons.

Comment 3

[Itiel]

(In reply to :Gijs (he/him) from comment #1)

We can probably remove this rule but we'd want to make sure that the back/fwd buttons, url bar, hamburger + overflow button etc. stay greyed out

fwiw there's also the All Tabs button in the tabs bar (which imo shouldn't be greyed out), which is currently is being greyed out in customize mode.

Comment 4

[Itiel]

(In reply to Itiel from comment #3)

fwiw there's also the All Tabs button in the tabs bar ...

... and the menubar, when active.

Comment 5

[:Gijs (he/him)]

(In reply to Itiel from comment #2)

(In reply to :Gijs (he/him) from comment #1)

I think it didn't get noticed before because the main item that's removable=false is the url bar, and greying that out made sense because it's disabled (doesn't make sense to navigate while in customize mode), so that seemed OK.

We can probably remove this rule but we'd want to make sure that the back/fwd buttons, url bar ... stay greyed out.

Not sure I understand your reasoning, AIUI buttons (or other items) should be greyed out in this context if they are not movable, not because they are uninteractionable (e.g. navigating using the address bar as you mentioned). According to your reasoning the searchbar should also be greyed out?

So, all the buttons and other UI elements are disabled in customize mode (or at least, not interactive/clickable).

Normally, disabled buttons are greyed out.

I assumed this was the same in customize mode but it appears I was wrong. Looks like we override that for aesthetic reasons.

I don't have strong feelings about the greyed-outness of the address or search bar, though the least disruptive thing would be to keep them the same. Ditto the overflow/hamburger button.

Does that help?