Spin-off from bug 418868: I tested installing the extension https://addons.mozilla.org/en-US/firefox/addon/4444. The icon used during installation was not the Tango icon normally used in Linux builds. This can be seen here: https://bugzilla.mozilla.org/attachment.cgi?id=305210 Reed explained: "It looks like if an add-on doesn't provide a valid icon, AMO provides an icon for use when installing, which just happens to be this old icon. " So AMO should use the Tango icon for Linux installs. Please let me know what sizes you need the tango extensions icon (and if there are any other platform specific icons used in AMO).
Component: Add-ons → Public Pages
QA Contact: add-ons → web-ui
Version: unspecified → 3.0
IMO, if we do this at all, it should only be for the API-returned icons and possibly xpinstall dialogs since those appear in-product. I don't think theming the normal site based on platform is something we want to (or could easily with our caching) do.
I agree that there isn't much point in theming the site based on platform (except for a very minor consistency win). However it would be nice to get the correct style of icon appearing in Firefox 3's chrome.
Summary: Not using platform specific extension icon while installing → Not using platform-specific extension icon while installing
See also: bug 430318 Should we take this for 3.2.*?
This should just be as simple as not giving xpinstall your default icon url when the extension has no icon of its own. You might however want to continue giving the default theme icon.
For the AMO API, should I then return an empty <icon> element if there isn't one supplied by the extension? Right now it returns the default one mentioned above.
Scrap my comment, fligtar's fix for bug 430318 solves this.
(In reply to comment #7) > Scrap my comment, fligtar's fix for bug 430318 solves this. > I think Dave was saying that if the icon is blank, Firefox will show the appropriate platform-specific icon. My fix for bug 430318 only changes the default to tango (Linux) and fixes transparency. There's still no platform detection.
(In reply to comment #6) > For the AMO API, should I then return an empty <icon> element if there isn't > one supplied by the extension? Right now it returns the default one mentioned > above. Originally I had planned to support that but something seems to be not working for that case, I think the security check on the icon url in the xml might be over-zealously failing when no url is present. I was talking about the InstallTrigger used to start installs from the AMO website. Not passing an icon there will use the default icon on the client.
When I install now I see a consistent default icon in all the boxes (https://static-cdn.addons.mozilla.net/media//img/addon-icons/default-32.png). It's not what you're calling "tango" (or maybe tango has changed since this bug was filed) but it's consistent and that's really what matters. Calling this fixed (or wontfix, depending on how you look at it).
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WONTFIX
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.