Closed Bug 928430 Opened 8 years ago Closed 7 years ago

[Australis] Addon buttons horizontal spacing in toolbar is wonky

Categories

(Firefox :: Toolbars and Customization, defect)

27 Branch
x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: phlsa, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [Australis:P3])

Attachments

(3 files)

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.
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.
Depends on: australis-addons
No longer depends on: australis-addons
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.
Summary: [Australis] Addon buttons are misaligned in toolbar and panel menu → [Australis] Addon buttons horizontal spacing in toolbar is wonky
Whiteboard: [Australis:P2] → [Australis:P3]
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!)
Flags: needinfo?(philipp)
(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).
Flags: needinfo?(philipp)
(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.
(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.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.