Open
Bug 1056234
Opened 11 years ago
Updated 3 years ago
Add support for a method in Component Utils that would check whether an object can be structured cloned or not
Categories
(Core :: XPConnect, defect)
Core
XPConnect
Tracking
()
REOPENED
People
(Reporter: robertbindar, Unassigned)
References
Details
It would be nice to have something like Cu.clonableInto(obj, target) or Cu.isClonable(obj) that would return true if "obj" can be cloned using the structured clone algorithm.
This would help avoiding situations like:
try {
Cu.cloneInto(obj, {});
} catch(e) {
obj = undefined;
}
Comment 1•11 years ago
|
||
Checking whether something can be structured cloned has side effects, no? Not only that, but those side effects can change whether the object is structured clonable or not.
So if this is meant for use on untrusted objects you can get situations like this:
if (Cu.clonableInto(obj, target))
Cu.cloneInto(obj, target); // oops, throws
Comment 2•11 years ago
|
||
Can you describe in more detail what kinds of objects you're running into that can't be cloned?
Comment 3•11 years ago
|
||
(Note that I've considered implementing a scriptable structured clone callback for Cu.cloneInto, such that people could fill the gaps themselves).
Comment 4•11 years ago
|
||
For information, this bug came from a review of bug 899585.
https://bugzilla.mozilla.org/show_bug.cgi?id=899585#c14
| Reporter | ||
Comment 5•11 years ago
|
||
bz: How could those side effects change whether the object is structured clonable or not? I'm not aware of the internal implementation of this algorithm, could you be more specific please?
bholley: let's say I have an object that contains some data fields of primitive types and a DOM object. Again, I'm not sure how the algorithm is implemented, but I was thinking maybe a function like that could avoid -potential- useless data copying performed by the algorithm before it throws that exception; and it would also be more intuitive to use "if(clonable(obj)) then clone(obj)".
Comment 6•11 years ago
|
||
> How could those side effects change whether the object is structured clonable or not?
Try this testcase:
var obj = {};
Object.defineProperty(obj, "foo", {
get: function() { obj.doc = document; return 5; },
enumerable: true
} )
window.postMessage(obj, "*");
window.postMessage(obj, "*");
The first postMessage call succeeds and modifies "obj" so it can no longer be structured cloned. The second postMessage call fails.
> I'm not aware of the internal implementation of this algorithm
Whether a vanilla object is structured clonable depends on whether the values of all its enumerable own properties are structured clonable.
| Reporter | ||
Comment 7•11 years ago
|
||
Thanks for your thorough answer, I haven't thought of that case. That means it is currently not possible to have such a function, or at least one that can be useful for usecases like that.
The problem is that I used nsIStructuredCloneContainer to serialize some content objects and apparently this interface uses different callbacks than xpc::CloneInto, callbacks that support the cloning of some DOM objects like ImageData; CloneInto doesn't, so I ended up in a situation like Comment 0 because the internal system message for b2g uses CloneInto. Maybe I should've used CloneInto too.
Comment 8•11 years ago
|
||
We should consider fixing CloneInto to handle ImageData...
| Reporter | ||
Comment 9•11 years ago
|
||
Can't we make those two use the same callbacks? I have no idea what this would imply, how hard it can be to do this, just asking
Comment 10•11 years ago
|
||
(In reply to Boris Zbarsky [:bz] from comment #8)
> We should consider fixing CloneInto to handle ImageData...
I think this should actually be really easy - NS_DOMWriteStructuredClone is already set on the JSRuntime, and handles this case. We just need to fix up the CloneInto callbacks to play nicely with the runtime-default callbacks.
Comment 11•8 years ago
|
||
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → INACTIVE
Updated•8 years ago
|
Status: RESOLVED → REOPENED
Resolution: INACTIVE → ---
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•