928430 - [Australis] Addon buttons horizontal spacing in toolbar is wonky

Status: RESOLVED INVALID

(Firefox :: Toolbars and Customization, defect)

Description

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

Attachment: Alignment errors in panel menu

Buttons for some addons are misaligned in the new panel menu and also look a little off in the toolbar. Looks like this happens mostly with buttons that went to the addon bar until Australis.

Comment 1

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

Attachment: Toolbar alignment issues

Comment 2

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

It happened to me with these extensions:
Buffer http://bufferapp.com/extras
1Password https://agilebits.com/extensions/mac/index.html

Comment 3

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

Attachment: Evernote-Panel-Misalignment.png

Evidently it is not just Addon-bar-buttons -- it happens with the Evernote helper as well, which normally goes into the toolbar.
Other buttons like Feedly and Readability work fine in the panel.

Comment 4

[:Gijs (he/him)]

The panel is (AFAICT) mostly the SDK fixes from bug 931092 still not being uplifted into m-c. Otherwise, there's also e.g. bug 942144 for the panel, and there are several others. Let's keep this about the toolbar, in which case I think P2 is too high.

Comment 5

[:Gijs (he/him)]

I looked at this just now. AFAICT this is because the '1P' icon has a bunch of margin/padding on its right, but none on its left. You can see this if you start dragging the icon (as it gets a blue outline).

I'd therefore want to nominate this bug for INVALID status, as it's a problem with the add-on that we can't really do much about. :-\

Philipp, is my analysis correct, or have I missed something? (quite possible!)

Comment 6

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

(In reply to :Gijs Kruitbosch from comment #5)
> I looked at this just now. AFAICT this is because the '1P' icon has a bunch
> of margin/padding on its right, but none on its left. You can see this if
> you start dragging the icon (as it gets a blue outline).
> 
> I'd therefore want to nominate this bug for INVALID status, as it's a
> problem with the add-on that we can't really do much about. :-\
> 
> Philipp, is my analysis correct, or have I missed something? (quite
> possible!)

You are right about the padding. The question is whether or not it would be a good idea to give buttons a minimum padding. I think this is already happening with regular toolbar buttons (which had a border drawn around them prior to australis).

Comment 7

[:Gijs (he/him)]

(In reply to Philipp Sackl [:phlsa] from comment #6)
> (In reply to :Gijs Kruitbosch from comment #5)
> > I looked at this just now. AFAICT this is because the '1P' icon has a bunch
> > of margin/padding on its right, but none on its left. You can see this if
> > you start dragging the icon (as it gets a blue outline).
> > 
> > I'd therefore want to nominate this bug for INVALID status, as it's a
> > problem with the add-on that we can't really do much about. :-\
> > 
> > Philipp, is my analysis correct, or have I missed something? (quite
> > possible!)
> 
> You are right about the padding. The question is whether or not it would be
> a good idea to give buttons a minimum padding. I think this is already
> happening with regular toolbar buttons (which had a border drawn around them
> prior to australis).

Ah, but this is an SDK button. It's (a) not a <toolbarbutton>, but a <toolbaritem> (so I think it wouldn't have had a border pre-Australis, but I'm not sure), and (b) the content is inside the iframe created by the SDK, so we can't control it very well. We could add padding around it but that'd just make the item wider, but still lopsided. (FWIW, you can use DOM Inspector to poke at the structure and its padding and so on here)

Generally, "mininum padding" isn't really how add-ons/DOM/CSS works. We do set some basic styles on any button, but add-ons are free to override them. If add-ons do unexpected things (or don't test well cross-platform), these kinds of situations happen, and it's basically up to the add-ons to fix them.

Comment 8

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

(In reply to :Gijs Kruitbosch from comment #7)
> Ah, but this is an SDK button. It's (a) not a <toolbarbutton>, but a
> <toolbaritem> (so I think it wouldn't have had a border pre-Australis, but
> I'm not sure), and (b) the content is inside the iframe created by the SDK,
> so we can't control it very well. We could add padding around it but that'd
> just make the item wider, but still lopsided. (FWIW, you can use DOM
> Inspector to poke at the structure and its padding and so on here)
> 
> Generally, "mininum padding" isn't really how add-ons/DOM/CSS works. We do
> set some basic styles on any button, but add-ons are free to override them.
> If add-ons do unexpected things (or don't test well cross-platform), these
> kinds of situations happen, and it's basically up to the add-ons to fix them.

I see…
When I wrote »minimum padding« I was thinking of a programmatic approach like using Javascript when creating the window to determine if the padding meets the minimum expectations. But that is likely too hacky.

As this appears to be more a matter of developer advocacy, I second setting this bug to INVALID.