I tried to write this simple code: CustomizableUI.createWidget({ id: "foo", type: "button", name: "Foo!", description: "It's Foo", removable: true, defaultArea: CustomizableUI.AREA_NAVBAR, allowedAreas: [CustomizableUI.AREA_PANEL, CustomizableUI.AREA_NAVBAR], icons: { "16": data.url('addon.png'), "32": data.url('addon.png'), "48": data.url('addon.png') }, onCommand: function(event) { console.log(event); } }); And here the results: <http://people.mozilla.com/~mferretti/files/australis-button.png> Not sure if I'm doing something wrong here, but I feel like it takes by default the icon sprite sheet for the button, and because there are no id with the right rules in the CSS to slice it, this is what is happening. The expected result is having a button with custom id and custom icon(s).

taking this to Australis M7

We're not going to implement that piece of API. Its use has been removed from the tree; all buttons are styled with CSS, as should SDK widgets. One rationale behind this is that it introduces quite a but maintenance to keep this API up-to-date when more and more dpi settings are added to the various platforms. Since CSS already implemented support for that - via `@media`-queries - we deemed it more appropriate to style everything using CSS. Hence you don't see us using this API ourselves! Needinfo-ing Blair to confirm this rationale.

Well, that's news to me. But I can understand that rationale, and it seems bug 880322 did indeed remove support (along with some other bug). So the question is: Can Jetpack work with that?

Yes, we can work with that! At the moment I basically use the "custom" type for everything, and to change icons, label and disabled button I access directly to the XUL node. I have only one request, if it's possible, that is only partially related to this bug – in fact, I will open another bug. We implement ourselves those API, so that the developer can specify different size for the same icon, and those size are applied based on the context (e.g. in the toolbar it uses 16x16, in the panel it uses 32x32). But the developer could also specify just one icon and that icon would be resized (it would look horrible I know): unfortunately, the xul:image of a toolbarbutton doesn't seems have any `height` constraint. It means, the 32x32 icon will be displayed as 16x32 and not resized, with the icon that exceeds the height of the button. I did a temporary workaround registering a stylesheet on the fly that modify that, but would be better if we could fix the CSS on platform side.

(In reply to Matteo Ferretti [:matteo] [:zer0] from comment #4) > But the developer could also specify just one icon and that icon would be > resized (it would look horrible I know): If the developer doesn't provide those sizes can we just throw an exception or fail? Letting add-on authors do the wrong thing (when we can easily prevent it) will just make our product look bad.

Matteo, what do you plan to do on the SDK side to prevent add-on authors from NOT doing the wrong thing? And what do you need from us to prevent it? You also talked about filing another bug that'd be more appropriate for this discussion?

Opened the bug 882910 to deal with that. Please, feel free to find a better "Summary" for it. :) To me this one can be a WONTFIX.

(In reply to Matteo Ferretti [:matteo] [:zer0] from comment #7) > Opened the bug 882910 to deal with that. Please, feel free to find a better > "Summary" for it. :) > > To me this one can be a WONTFIX. Great, I'll do as you wish.