Closed
Bug 852726
Opened 12 years ago
Closed 12 years ago
Type information is lost for properties of a dictionary passed as nsIVariant/jsval
Categories
(Core :: XPConnect, defect)
Core
XPConnect
Tracking
()
RESOLVED
INVALID
People
(Reporter: reuben, Unassigned)
References
Details
In the Settings API, we have the following method:
// Contains a JSON object with name/value pairs to be set.
nsIDOMDOMRequest set(in nsIVariant settings);
Content then calls:
lock.set({"pref name": pref_value});
If pref_value is e.g. an nsIDOMBlob, |pref_value instanceof Ci.nsIDOMBlob| is false in the set() code. It is seen as a plain object.
Comment 1•12 years ago
|
||
what are the security characteristics of the caller and the callee here?
Reporter | ||
Comment 2•12 years ago
|
||
Caller is unprivileged content, callee is chrome code on the child process. If I pass the nsIDOMBlob directly (for example by changing set to be |set(in jsval name, in nsIVariant value)|, the type is preserved. The relevant code is here: http://mxr.mozilla.org/mozilla-central/source/dom/settings/SettingsManager.js#91
Reporter | ||
Comment 3•12 years ago
|
||
So, turns out the Settings code stringifies the settings object twice, one on the entire dictionary and then on the individual settings. Because I didn't see/remove the former, I was getting plain old JS objects.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•