bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

Serialized JSON preference escaping lost when generating xpi

RESOLVED WONTFIX

Status

Add-on SDK
General
RESOLVED WONTFIX
5 years ago
4 years ago

People

(Reporter: Heffebaycay, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 (Beta/Release)
Build ID: 20131205075310

Steps to reproduce:

I created an add-on with a serialized JSON string as default value for a string preference.

Here is the content of my 'package.json' file:


{
  "name": "addon-name",
    <snip>
  "preferences": [{
      "name": "jsonPrefs",
	  "type": "string",
	  "title": "JSON Prefs",
	  "hidden": false,
	  "value": "{\"label\": \"Test\"}"
	}]
}



Actual results:

When generating the XPI file with the "cfx xpi" command, here is the content of the 'defaults/preferences/prefs.js' file:

pref("extensions.snip@jetpack.jsonPrefs", "{"label": "Test"}");


All the escaping from package.json is lost, and the JS code generated is invalid. Interestingly, "harness-options.json" also contains the default value for this preference but the escaping is done properly there.

Since this JS file is broken, the add-on will fail to load when installed in Firefox.


Expected results:

The following line should have been generated in 'defaults/preferences/prefs.js' within the xpi file for my add-on:

pref("extensions.snip@jetpack.jsonPrefs", "{\"label\": \"Test\"}");


The Python code responsible for generating this JS file seems to be located in "<addon-sdk-root>/python-lib/cuddlefish/options_defaults.py"
Double-escaping should work for now. Cfx itself is going away in the hopefully near future, so hopefully this problem goes away with it.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WONTFIX
Another workaround could be to set your value on install in main.js
You need to log in before you can comment on or make changes to this bug.