947647 - Australis - Provide better styling for "resized" menu panel icons

Status: RESOLVED WONTFIX

(Firefox :: Toolbars and Customization, enhancement)

Description

[Tim Nguyen :ntim]

Add-ons currently provide smaller icons, not optimized for Menu panel. Instead of resizing icons, it would be nice to apply a container with the biggest provided icon centered in it. It will help no longer developed add-ons to look better. I'll attach a mockup later.

Also, this is unrelated, but I think the widgets that create a panel or a menu could automatically be converted into a panel subview when they are in the menu. This would be both easier for Firefox and add-on developers. It would be useful for the share or downloads panel for example. A parameter could be added in the button/customization api like : auto-convert-to-subview:true and would default to true by default.

Comment 1

[Matthew N. [:MattN]]

Please file new bugs blocking australis-merge. Did one of the core Australis developers tell you to mark this as "M-"? If not, please change to "M?"

Comment 2

[Tim Nguyen :ntim]

(In reply to Matthew N. [:MattN] from comment #1)
> Please file new bugs blocking australis-merge. Did one of the core Australis
> developers tell you to mark this as "M-"? If not, please change to "M?"
Done :)

Comment 3

[Tim Nguyen :ntim]

I think it could somehow like Stephen's concepts for small icons in awesome bar.

Comment 4

[Paul Silaghi, QA [:pauly]]

Did something change here?

Comment 5

[Tim Nguyen :ntim]

(In reply to Paul Silaghi, QA [:pauly] from comment #4)
> Did something change here?

Hmm, no ? Small icons are still scaled up.

Comment 6

[Tim Nguyen :ntim]

Stephen, How do you think this could look ?

Comment 7

[Tim Nguyen :ntim]

How easy is it to implement something like [1] instead of blurry icons ? I would say that it requires a new XUL binding, but I'm not a huge expert at that level.

[1] https://wiki.mozilla.org/images/d/d9/AwesomeBarResults-16x16-Colored-Border.png

Comment 8

[:Gijs (he/him)]

(In reply to Tim Nguyen [:ntim] from comment #7)
> How easy is it to implement something like [1] instead of blurry icons ? I
> would say that it requires a new XUL binding, but I'm not a huge expert at
> that level.
> 
> [1]
> https://wiki.mozilla.org/images/d/d9/AwesomeBarResults-16x16-Colored-Border.
> png

I don't think even a new binding would fix anything here. The problem is that we don't *know*, on our side of the code, what size the images are. We'd have to read computed style information, load the image, check its size, and then decide to do something else, which I will guarantee you [tm] will cause an ugly flash of imperfect content.

To be quite honest, I don't think this issue is worth fixing, and I would suggest wontfix.

Comment 9

[Tim Nguyen :ntim]

(In reply to :Gijs Kruitbosch from comment #8)
> (In reply to Tim Nguyen [:ntim] from comment #7)
> > How easy is it to implement something like [1] instead of blurry icons ? I
> > would say that it requires a new XUL binding, but I'm not a huge expert at
> > that level.
> > 
> > [1]
> > https://wiki.mozilla.org/images/d/d9/AwesomeBarResults-16x16-Colored-Border.
> > png
> 
> I don't think even a new binding would fix anything here. The problem is
> that we don't *know*, on our side of the code, what size the images are.
> We'd have to read computed style information, load the image, check its
> size, and then decide to do something else, which I will guarantee you [tm]
> will cause an ugly flash of imperfect content.
> 
> To be quite honest, I don't think this issue is worth fixing, and I would
> suggest wontfix.

Well, here's a demo at put up : http://jsfiddle.net/ntim/Bhh5p/

Anyways, I would never put addons into my menu-panel. There is no such reason to do so. Especially when they look scaled up and inconsistent compared to other buttons. Do you think it's possible somehow to implement my solution ?

Comment 10

[:Gijs (he/him)]

(In reply to Tim Nguyen [:ntim] from comment #9)
> (In reply to :Gijs Kruitbosch from comment #8)
> > (In reply to Tim Nguyen [:ntim] from comment #7)
> > > How easy is it to implement something like [1] instead of blurry icons ? I
> > > would say that it requires a new XUL binding, but I'm not a huge expert at
> > > that level.
> > > 
> > > [1]
> > > https://wiki.mozilla.org/images/d/d9/AwesomeBarResults-16x16-Colored-Border.
> > > png
> > 
> > I don't think even a new binding would fix anything here. The problem is
> > that we don't *know*, on our side of the code, what size the images are.
> > We'd have to read computed style information, load the image, check its
> > size, and then decide to do something else, which I will guarantee you [tm]
> > will cause an ugly flash of imperfect content.
> > 
> > To be quite honest, I don't think this issue is worth fixing, and I would
> > suggest wontfix.
> 
> Well, here's a demo at put up : http://jsfiddle.net/ntim/Bhh5p/
> 
> Anyways, I would never put addons into my menu-panel. There is no such
> reason to do so. Especially when they look scaled up and inconsistent
> compared to other buttons. Do you think it's possible somehow to implement
> my solution ?

I'm not sure, but I can't think of a way to do it offhand.

XUL boxes sadly are different than HTML ones. We currently set the horizontal margins to be exactly correct considering the sizing of the outer button in em, minus the 32 pixel icon in the middle, and changing that to margin: auto breaks it, if I recall correctly.

We can't insert a separate box to center the icon within those 32 pixels, because we'd need different bindings, which leads to the "binding multiplication problem" (for every possible binding (type="checkbox", type="menu", type="menu-button", etc.), you'd need to write a separate binding) and also doesn't work on add-ons which have custom bindings (of which there are more than I'd like).

Between those two things, I don't see how we can respect the intrinsic size of the images and center them correctly as you suggest. :-(

Comment 11

[Tim Nguyen :ntim]

What about extracting the 32*32 px icon from the add-on manager ? After all, we have it, why not use it ? The only challenge would be to check if the icon used is 32px or not.

Comment 12

[:Gijs (he/him)]

(In reply to Tim Nguyen [:ntim] from comment #11)
> What about extracting the 32*32 px icon from the add-on manager ? After all,
> we have it, why not use it ? The only challenge would be to check if the
> icon used is 32px or not.

There is no way to know what add-on a button belongs to (ie no connection between some add-on calling CustomizableUI.createWidget, or creating a XUL widget, and the add-on ID and therefore its representation in the add-on manager. This is also why all the SDK widget add-ons have the same icon in customize mode.)

Furthermore, not all add-ons ship with a 32x32 or 64x64 or whatever icon to show in the add-ons manager.

Even if we could solve all these problems, it'd be a lot of code for very little gain - it's 3 lines of CSS + an image to fix this on the add-on author's side. I don't think we should invest time in this - there are a lot more high-impact things we could do with the time required to fix this.