Addon icons disappear in customize panel. 1. Install Freenode IRC client add-on https://addons.mozilla.org/en-US/firefox/addon/freenode-irc-client/ 2. Open Firefox Nightly (29.xx) 3. Click on Customize & Control Night Icon on panel 4. Click on (+ Customize) button. The add-on icon is replaced by text description. Perhaps we need to show both icon and description matching Firefox style. See attached screenshot.

Wonder if Australis/widget changes caused this -- Matteo, have any idea what this could be?

This is made on purpose on Firefox code itself, not on SDK. For SDK widgets, we can't show the icon because, well, it's not an icon, it's an iframe that point on an icon. This was made by fx-team in order to keep a sort of compatibility with SDK widgets; but SDK widgets unfortunately doesn't really scale well on Australis, and that's why we implemented the new UI components and we have deprecated widgets. With Australis, is strongly recommended to use the new API rather than widgets, in order to avoid such user experience. Gijs maybe could provide some additional information about that, if I'm correct he's the one made that changes on Firefox.

Probably related to bug 959640.

(In reply to Matteo Ferretti [:matteo] [:zer0] from comment #3) > Probably related to bug 959640. Right. Unless the SDK knows about the icon specifically, we can't fix this, and the best we can do is bug 959640 (where, funny story, I just needinfo'd Matteo for help :-) ). Does the SDK know anything here?

(In reply to :Gijs Kruitbosch from comment #4) > Right. Unless the SDK knows about the icon specifically, we can't fix this, No, the SDK takes just an URL to load in the iframe, and it can be anything; local and remote content. We could try to check if it's an icon once the frame is loaded, using the content type of the document itself and if it is, use that icon. But bug 959640 needs to be fixed upfront: once we have a default icon, we could probably check the possibility to show a more specific widget icon. The widget's iframe content also could be changed during the life time of the add-on, so I would limit the check part to the content given to the widget's constructor. It sounds good? > and the best we can do is bug 959640 Agreed. > (where, funny story, I just needinfo'd > Matteo for help :-) ). Does the SDK know anything here? :) I just replied on the other bug, we can work together to solve that, so that I can try to fix this one too. I would made this bug depends by bug 959640

(In reply to Matteo Ferretti [:matteo] [:zer0] from comment #5) > No, the SDK takes just an URL to load in the iframe, and it can be anything; > local and remote content. We could try to check if it's an icon once the > frame is loaded, using the content type of the document itself and if it is, how about taking a snapshot, or "thumbnail"? - the dimensions are known (16px height, widget.width || 16px) - would work both for simple icons and any other random html - the code might even be simpler, as we already have: https://github.com/mozilla/addon-sdk/blob/master/lib/sdk/content/thumbnail.js

(In reply to Tomislav Jovanovic [:zombie] from comment #6) > how about taking a snapshot, or "thumbnail"? > > - the dimensions are known (16px height, widget.width || 16px) UX doesn't want to deal with wide widget, or non square icon for add-on (that's why in the new Button API only squares are allowed atm). I think it's better just apply this mechanism to those widgets that are actually just buttons, but because lack of previous good API they had to use SDK widget with the all iframe stuff. It's also less expensive in term of code execution. I will stick to use the proper image if given as contentURL, and the default one for the rest. If someone complaints about it maybe we could open another bug, and use the thumbnail approach for HTML documents only. So basically something like: // when the iframe is loaded if (iframeDocument.contentType.startsWith('image/')) // set directly to the XUL button the widget's contentURL as image else // calculate the thumbnails Consider that most of the jetpack add-ons uses widgets just for a button, only few add-ons actually have complex HTML UI (they're the "wide widget" add-ons, that we considered for Australis a minority). Another thing we could do, is using the add-on's icon/icon64 itself if provided.

(In reply to Matteo Ferretti [:matteo] [:zer0] from comment #2) > This is made on purpose on Firefox code itself, not on SDK. For SDK widgets, > we can't show the icon because, well, it's not an icon, it's an iframe that > point on an icon. This was made by fx-team in order to keep a sort of > compatibility with SDK widgets; but SDK widgets unfortunately doesn't really > scale well on Australis, and that's why we implemented the new UI components > and we have deprecated widgets. What is the new UI component that we're supposed to use instead of widgets? Thanks, Monica

(In reply to Monica Chew [:mmc] (please use needinfo) from comment #9) > What is the new UI component that we're supposed to use instead of widgets? As I said in bug 978838, the `sdk/ui` components, as buttons and toolbars. See: https://developer.mozilla.org/en-US/Add-ons/SDK/Low-Level_APIs/ui_button_action And basically everything under `sdk/ui`.

We are removing the widget module in bug 1118364 very soon.