Not using platform-specific extension icon while installing

RESOLVED WONTFIX

Status

P5
enhancement
RESOLVED WONTFIX
11 years ago
3 years ago

People

(Reporter: micmon, Unassigned)

Tracking

4.x (triaged)
x86
Linux

Details

(Reporter)

Description

11 years ago
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.*?
erm, 3.4.*
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.

Comment 6

11 years ago
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.

Comment 7

11 years ago
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.

Updated

10 years ago
Target Milestone: --- → 3.x (triaged)
Severity: normal → enhancement
Priority: -- → P5
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
(Assignee)

Updated

3 years ago
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.