1025315 - only run sdk/preferences/native-options.enable() if optionsURL is data:text/xml,<placeholder/>

Status: RESOLVED INCOMPLETE

(Add-on SDK Graveyard :: General, defect, P2)

Description

[Erik Vold [:erikvold] (please needinfo? me)]

In bug 1011813 I disabled this by mistake, we should re-enable it and add a test for this so that I can't break it again.

Comment 1

[Erik Vold [:erikvold] (please needinfo? me)]

ok at the moment we have this:

Add-ons made with pre 1.16 will not use the `sdk/preferences/native-options.enable()` function and therefore are unaffected by changes.  Newer add-ons will not have an auto-generated options.xul file, and if they include a "preferences" key in their "package.json" file then `sdk/preferences/native-options.enable()` will be used, either in combination with a options.xul file provided by the developer or with the default `data:text/xml,<placeholder/>` value that is now used.

When `sdk/preferences/native-options.enable()` is used with a custom options.xul file, the preferences defined in the "preferences" key of the package.json file will be added to the options.xul file and the entire document will be localized.  I think this could be useful in some use cases, at worst it is a little confusing, and there is no harm in keeping this the way that it is, in fact I prefer it this way.

So I think we should leave this the way that it is until we get some feedback.

Comment 2

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

That sounds fine by me, although zombie may have some insights that we're failing to see, so I'd like to hear his point of view too.

Comment 3

[Tomislav Jovanovic :zombie]

> Add-ons made with pre 1.16 will not use the
nit: this didn't make it for sdk 1.16, so we are discussing only jpm-packed (non-native) addons.


anyway, not that i'm strongly against this, i just don't see that described scenario as common enough, and as useful enough to outweigh added complication of documenting/explaining this, and possible confusion when it happens to those that don't intend to use it (hard to debug possibly?)

anyone who would find it useful would not have a hard time replicating the described benefits themselves, so i would vote for a simpler/cleaner solution of either-or, use xul or simple-prefs..

Comment 4

[Erik Vold [:erikvold] (please needinfo? me)]

I wanted to try to take a look at this, but I'm not sure that I will be able to now.

Comment 5

[Erik Vold [:erikvold] (please needinfo? me)]

There is a work around in place for jpm atm https://github.com/mozilla/jpm/blob/47823454d7bd756af71207bffc52e1779ddb96c1/lib/rdf.js#L64  so only native-jetpacks depend on this.

Comment 6

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1399562