Relative icon paths do not work

[johannhof]

cfx includes icon.png and icon64.png in the base directory of the Add-on, as described here.

jpm does not include icon.png and icon64.png, but instead adds them to the install.rdf, which is unnecessary.

[erikvold]

we only need to write the <iconURL> node if it is explicitly defined in the package.json

[jeffgca]

This has been a bug forever, and is a gap from cfx's existing behaviour ( people have reported this issue ). @erikvold what is the issue here? When I build an xpi with jpm 0.25 the icon does not show up, even though when I unpack my extension the files are in the right spot and the install.rdf looks correct:

<?xml version="1.0" encoding="utf-8"?>
<RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:em="http://www.mozilla.org/2004/em-rdf#">
    <Description about="urn:mozilla:install-manifest">
          <em:id>transmission-web-helper@canuckistani.ca</em:id>
          <em:type>2</em:type>
          <em:bootstrap>true</em:bootstrap>
          <em:unpack>false</em:unpack>
          <em:version>0.0.5</em:version>
          <em:name>transmission-web-helper</em:name>
          <em:description>a basic add-on</em:description>
          <em:creator>Jeff Griffiths</em:creator>
          <em:iconURL>icon.png</em:iconURL>
          <em:icon64URL>icon64.png</em:icon64URL>
          <em:optionsURL>data:text/xml,&lt;placeholder/&gt;</em:optionsURL>
          <em:optionsType>2</em:optionsType>

          <em:targetApplication>
            <Description>
              <em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id>
              <em:minVersion>33.0a1</em:minVersion>
              <em:maxVersion>38.0</em:maxVersion>
</Description>
</em:targetApplication>
    </Description>
</RDF>

[erikvold]

@canuckistani I was giving @johannhof a chance to complete his pull request while I worked on other things.

[johannhof]

@canuckistani Yes, @erikvold and I talked about it on irc a few weeks ago and it's apparently solvable in two ways:

1. Resolve the iconURL to absolute paths (resource://whatever) in jpm
2. Fix it in the addon-sdk

I asked if I could work on that, but didn't progress so far. I'd still like to do it (we can also chat about it) but if it's high prio right now obviously feel free to take over. :)

[jeffgca]

@johannhof @erikvold I think this needs to be addressed before releasing jpm. Do you have any more details on where this is broken in the SDK? Sounds like a better approach.

[ghost]

Using jpm 0.0.29, I have this in my package.json:

    "icon": "data/images/flag48.png",
    "icon64": "data/images/flag64.png",

My generated install.rdf:

<em:iconURL>data/images/flag48.png</em:iconURL>

Doesn't even have an <em:icon64URL> ?

[erikvold]

ya the structure that should be used is:

 "icon": {
  "48": "data/images/flag48.png",
  "64": "data/images/flag48.png"
}

but this still won't display the icon desired because it will generate an install.rdf with

<em:iconURL>data/images/flag48.png</em:iconURL>

like you mentioned, relative icon uri paths do not work at the moment, even when this is implemented the icons will not be displayed when the add-on is disabled unless the icons are in the default location, so I would recommend that implementation regardless.

[erikvold]

@canuckistani Yes, @erikvold and I talked about it on irc a few weeks ago and it's apparently solvable in two ways:

1. Resolve the iconURL to absolute paths (resource://whatever) in jpm

So I thought more about this @johannhof and I don't think this method is viable because we plan to implement new uris and not use resource: uris in the future, so resolving these icon uris with jpm xpi would mean that bug 779197 would cause regressions here, which we want to avoid.

2. Fix it in the addon-sdk

This will need to fixed in m-c actually.

[erikvold]

I made bug 1141839 for this, and I think we should track progress there.

[dave-watts]

Is there a workaround for a user who wants to see an icon in a jpm extension?

[erikvold]

@dave-watts using the default locations icon.png and icon64.png in the root is the best option for now, the next best option is to use an absolute path for the time being.

[Yonezpt]

@erikrose what are the default locations for the icons? If I leave the icon in the root folder of the add-on (where the package and main.js are) and insert the icon path as

{
    "title": "Add-on Title",
    "name": "addonname",
    "version": "0.0.1",
    "description": "add-on description",
    "main": "main.js",
    "icon": "icon.png"
}

The icon doesn't show up. If I leave it on the same place and don't include the icon path on the package file it also doesn't work.

If I repeat the same steps, but instead place it inside the data folder it also doesn't work.

If I use the above mentioned icon path format:

 "icon": {
  "48": "icon.png"
}

It also doesn't work. It only works if I use a direct path to the icon like so

"icon": "resource://@addonname/icon.png"

But this is a problem because now I cannot use any add-on ID like website@domain.com because if I do and change the above path to either

"icon": "resource://website@domain.com/icon.png"

or

"icon": "resource://@website@domain.com/icon.png"

It still won't show the icon.

Since the relative paths issue is still pending a fix for 9 months it would be best to have reliable information explaining how the developer can use the icons in the default location without preventing him from using an ID, especially with the jpm platform getting close to replace cfx permanently.

Could you show a working and valid example on how we can use the icons in the default location without having to use direct paths which prevents us from adding our add-on id? I'm ok with using default locations for this as long as I am able to also use an ID for my add-on, otherwise I am stuck with cfx until this issue gets fixed.

[Yonezpt]

@grbradt If I do it like you and leave it in the root folder without referencing the icon path in the package.json file it doesn't work for me, it only shows an empty space where the icon should appear.

EDIT: I was finally able to figure it out. The problem lies with the jpm module, for some reason it is adding the relative icon paths to the rdf file even if we don't include them in the package.json file.

So the solution seems to be to package the addon, extract it with winrar/winzip to a new folder, edit the rdf file, remove any icon reference, save it, package that extracted folder into another .xpi and only then the icon will show up.

Also there is another problem, JPM is artificially limiting the browser version to 38, so no matter what version I insert it will never get past 38 unless we use a version that is above 38, which will then increase the limit to 39, but never to 40. Again this has to be changed in the rdf file manually.

[ronald05arias]

Can someone reopen this? It is still an issue. Any updates on it? Besides manually patching the rdf. Thanks.

[ronald05arias]

For now, with JPM 1.0.0 this works:
manifest.json:

icon: {
    "48": "icon.png",
    "64": "icon64.png
}

This way the compiler will delete the entries in the install.rdf, effectively applying the patch.
According to this commit: f15069d#diff-dc54654b4741edd9be2ea246c9563573R56

Also don't forget to copy your icon.png and icon64.png into the root directory.

[kwent]

@ronald05arias Thank you for the tips. Works perfectly !

[montjoile]

it's still not working on jpm 1.0.1
the only way it works is:

    "icon": "resource://@youraddonname/icon.png",

rename your icon as "icon". Don't know why it works that way..

[Yonezpt]

Has this issue been forgotten in the new version update?

[anaran]

I have opened #341 to hopefully draw some attention.

Also see https://developer.mozilla.org/en-US/Add-ons/SDK/Tools/package_json#icon

[jokester]

A workaround with jpm 1.1.4 and Firefox 48/50:

• Name the icon icon.png and place it in root dir of addon.
• Write no "icon": ... entry in package.json

[yan12125]

Hmm, I thought my pull request #498 had fixed it.