Closed Bug 1025315 Opened 8 years ago Closed 4 years ago
only run sdk/preferences/native-options
.enable() if options URL is data:text/xml,<placeholder/>
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.
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.
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.
> 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..
Priority: -- → P2
I wanted to try to take a look at this, but I'm not sure that I will be able to now.
Assignee: evold → nobody
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.
No longer blocks: jpm
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.