960694 - Support serializing JS implemented objects in nsBinaryOutputStream

Status: RESOLVED FIXED

(Core :: XPCOM, defect)

Description

[Johnny Stenback (:jst)]

We ran into this in bug 911547 where we need to serialize a CSP object which is implemented in JS. The nsBinaryOutputStream calls GetClassIDNoAlloc() on the object's classinfo, which in this case is also a JS implemented object, and thus can not implement GetClassIDNoAlloc() (which is a [notxpcom] method).

We probably want to keep calling GetClassIDNoAlloc(), cause it's faster and does exist in the common case, but if it fails, we should fall back on the scriptable method.

Comment 1

[Johnny Stenback (:jst)]

Attachment: Support writing out JS implemented classes.

Comment 2

[Benjamin Smedberg]

FWIW, I'm trying a patch now which just replaces GetClassID with GetClassIDNoAlloc and makes that one scriptable (there's no reason it shouldn't be scriptable, from what I can see). We'll see whether it actually works and is scriptable in reality in a bit. If that doesn't pan out, this is fine.

Comment 3

[Benjamin Smedberg]

Comment on attachment 8361259 [details] [diff] [review]
Support writing out JS implemented classes.

Yeah so, making this an nsIDRef gives the right signatures but xpconnect isn't prepared to handle it *and* currently doesn't distinguish between nsIDPtr and nsIDRef, which is strange. So land this as is and I'll see if I can unify them in a followup.

Comment 4

[Sid Stamm [:geekboy or :sstamm]]

Landed on inbound: https://hg.mozilla.org/integration/mozilla-inbound/rev/e0667142d36a

Comment 5

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/e0667142d36a

Comment 6

[Sid Stamm [:geekboy or :sstamm]]

Comment on attachment 8361259 [details] [diff] [review]
Support writing out JS implemented classes.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): prevents serialization of js-implemented xpcom objects.
User impact if declined: can't uplift bug 911547.
Testing completed (on m-c, etc.): landed on m-c
Risk to taking this patch (and alternatives if risky):  low risk; no js-implemented objects that are currently serialized exist in mozilla-aurora 
String or IDL/UUID changes made by this patch: none

Comment 7

[(PTO June 19-July 7) Ryan VanderMeulen]

https://hg.mozilla.org/releases/mozilla-aurora/rev/d6269ead6ff3