519063 - Need a way of having application specific information for optionsURL (and possibly other entries)

Status: RESOLVED WONTFIX

(Toolkit :: Add-ons Manager, defect)

Description

[Ian Neal]

At the moment there is one overall optionsURL entry in install.rdf files.
If you have an add-on that is for more than one application (e.g. lightning) then it would be very useful to be able to have multiple optionsURL entries - one for each application - as they are likely to have different paths to where the preferences are in chrome if the add-on overlays the existing preference dialog than having its own discrete one.

The structure would be something like:
<em:targetApplication>
  <Description>
    <em:id>{App-ID}</em:id>
    <em:minVersion>1.0</em:minVersion>
    <em:maxVersion>4.0</em:maxVersion>
    <em:description>An fab add-on for App-Name</em:description>
    <em:optionsURL>chrome://path/to/app/preferences.xul</em:optionsURL>
  </Description>
</em:targetApplication>

For compatibility with older add-ons if an application specific entry cannot be found it looks for the overall one.

Comment 1

[Dave Townsend [:mossop]]

I don't see anything here that cannot be handled using an application specific override in the chrome.manifest.

Comment 2

[Ian Neal]

(In reply to comment #1)
> I don't see anything here that cannot be handled using an application specific
> override in the chrome.manifest.
So in the case of the lightning add-on which has its optionsURL set to chrome://messenger/content/preferences/preferences.xul (which is TB's pref window), then to let that add-on be used for SeaMonkey too the chrome.manifest has to have in:
override chrome://messenger/content/preferences/preferences.xul chrome://communicator/content/pref/preferences.xul
Would it be Lightning's chrome.manifest or elsewhere?

Comment 3

[Dave Townsend [:mossop]]

(In reply to comment #2)
> (In reply to comment #1)
> > I don't see anything here that cannot be handled using an application specific
> > override in the chrome.manifest.
> So in the case of the lightning add-on which has its optionsURL set to
> chrome://messenger/content/preferences/preferences.xul (which is TB's pref
> window), then to let that add-on be used for SeaMonkey too the chrome.manifest
> has to have in:
> override chrome://messenger/content/preferences/preferences.xul
> chrome://communicator/content/pref/preferences.xul
> Would it be Lightning's chrome.manifest or elsewhere?

I'd be more inclined to set the optionsURL to something Lightning specific then override that to the application options url for each application. You'd do it in Lightning's chrome.manifest.

Comment 4

[Ian Neal]

Okay, I've tried both of the following in Lightning's chrome.manifest file:
override chrome://messenger/content/preferences/preferences.xul chrome://communicator/content/pref/preferences.xul application={92650c4d-4b8e-4d2a-b7eb-24ecf4f6b63a}
override chrome://communicator/content/pref/preferences.xul chrome://messenger/content/preferences/preferences.xul application={92650c4d-4b8e-4d2a-b7eb-24ecf4f6b63a}
Either way I still get a window with the following error message:
The file jar:file:///mozdev/obj-suite-opt/mozilla/dist/bin/chrome/messenger.jar!/content/messenger/preferences/preferences.xul cannot be found.

Comment 5

[Ian Neal]

See https://bugzilla.mozilla.org/show_bug.cgi?id=518736#c13 for a hack round the issue, I rather get a neater approach.

Comment 6

[Robert Kaiser]

A mechanism like requested here would also help add-ons that work in both Firefox desktop and mobile, as they need different options handling.

Comment 7

[Andrew Swan [:aswan]]

We no longer support install.rdf