Implement transferable/cloneable objects

[jdm]

Spec: https://html.spec.whatwg.org/multipage/infrastructure.html#transferable-objects, https://html.spec.whatwg.org/multipage/infrastructure.html#cloneable-objects

We currently do not pass pointers to JSStructuredCloneCallbacks when calling JS_WriteStructuredClone and JS_ReadStructuredClone. These callbacks control what to do when DOM objects are encountered in the structured clone algorithm. We'll need to duplicate what Gecko does to support this in Servo.

[jdm]

This support is necessary for the transferable arguments to postMessage, which allows sending complex DOM objects between the main thread and workers.

[fflorent]

Hi @jdm! What are the requirements to be able to take this issue?

Florent

[jdm]

Ability to read Gecko's C++ code (as linked in the original comment) and translate that into equivalent Rust code, mainly!

[KiChjang]

This would be a nice thing to have for MessagePort as well. We currently have some code that deals with structured clones in components/script/dom/bindings/structuredclone.rs.

[gterzian]

Is someone already working on this one? If not, I would be happy to give it a try...

[jdm]

Let's give @fflorent the right of first refusal here.

[KiChjang]

I'd also highly encourage the person to work on this discuss the implementation plan here first before attempting.

[fflorent]

Sure take it! :)

Florent

[gterzian]

@fflorent thanks!

@KiChjang @jdm I'll take some time to look into this, and will come back to discuss the implementation first :)

[gterzian]

Hi there, I've started looking into this, and the first questions I have are:

The stuff found in https://github.com/servo/rust-mozjs/, are those just stubs or actual implementations as well? For example I see Servo is using JS_WriteStructuredClone but I can't find the actual implementations, either in rust_mozjs or Servo.

Same thing for JSStructuredCloneCallbacks, are those actually implemented somewhere?

Looking at the Firefox code, I can see the actual callbacks implementation, so I'm wondering, does this issue require implementing those callbacks? If so, would that be done in rust_mozjs? Or are those already implemented and do they just need to be glued into Servo?

[KiChjang]

@gterzian rust-mozjs is a repository for Rust bindings to the JavaScript engine that we use called SpiderMonkey. It is essentially the js directory in Gecko.

[gterzian]

@KiChjang thanks for the info. Why is it that those JSStructuredCloneCallbacks are found within rust_mozjs, while in gecko they are in the dom folder, not js?

EDIT: I think I get it, the stuff in js are the basic types, the stuff in dom the actual implementations.

[gterzian]

Ok so here is what I can make out of the Gecko code:

• There is this dom/base/StructuredCloneHolder.
• Sometimes directly, sometimes through a lot of indirection, this StructuredCloneHolder ends up calling the various JS_* operations in js/public/StructuredClone.h
• StructuredCloneHolder also defines a bunch of StructuredCloneHolder::sCallbacks, which are basically implementations of JSStructuredCloneCallbacks found in js/public/StructuredClone
• When calling the various JS_* operations, it passes around those StructuredCloneHolder::sCallbacks
• When those callbacks end up being called, they in turn call handler operations back in dom/base/StructuredCloneHolder. For example StructuredCloneCallbacksRead will call CustomReadHandler, and return the value back to the caller of the callback...
• There are also a bunch of StructuredCloneTags, which are used in the handler operations to handle various types of cloned values being read/written.

So basically, like Gecko, we need to:

• implement those callbacks as a struct , using the JSStructuredCloneCallbacks types found here https://github.com/servo/rust-mozjs/blob/master/src/jsapi_macos_64.rs#L2246
• Pass this struct around instead of the current ptr::null() when calling operations like JS_WriteStructuredClone and JS_ReadStructuredClone
• Implement appropriate handlers for each callbacks.

So my question now is, am I getting it somewhat right? And also, am I right to think that, while we can implement all the callbacks, we should probably just start with one or two handler operations? I believe you mentioned two potential use cases("transferable arguments to postMessage" and "MessagePost"), so we should probably just do those for now?

[jdm]

Yep, that sounds like a correct summary of how all the pieces fit together. I think implementing stubs for all of the callbacks makes the most sense; we will presumably need some kind of delegation like https://dxr.mozilla.org/mozilla-central/rev/1d025ac534a6333a8170a59a95a8a3673d4028ee/dom/base/StructuredCloneHolder.cpp#62-65, and then we can focus on supporting a single small use case like using postMessage to clone a Blob object when communicating with a worker.

[gterzian]

@jdm awesome, thanks! I'll get started then...

[gterzian]

first pass at #15519, if you could please take a look...