Review of structured clone algorithms

[syg]

We reached consensus on the general idea of taking over maintainership of the structured clone algorithm in the October 2021 TC39, pending a requested review by @erights of the concrete algorithm proposed to be refactored into ecma262.

The two algorithms proposed to be copied are StructuredSerializeInternal and StructuredDeserialize.

For StructuredSerializeInternal:

• Steps 19 and 20 will be refactored out, as they deal with non-ES values.
• All occurrences of "throw a "DataCloneError" DOMException" will be changed to "throw a host-defined exception".

For StructuredDeserialize:

• Step 20 and all its substeps will be refactored out since it deals with non-ES values.
• All occurrences of "throw a "DataCloneError" DOMException" will be changed to "throw a host-defined exception".

[ljharb]

Can we specify what non-browsers must throw, and use annex b-like wording so that browsers must use a domexception per html?

[syg]

Can we specify what non-browsers must throw, and use annex b-like wording so that browsers must use a domexception per html?

What does Node throw today? And are you planning to include Node as a browser?

[Jack-Works]

All occurrences of "throw a "DataCloneError" DOMException" will be changed to "throw a host-defined exception".

What about abort the AC with an AbortCompletion?

[Jack-Works]

Can we specify what non-browsers must throw, and use annex b-like wording so that browsers must use a domexception per html?

What do you mean? Do you mean non-browser must throw with ES Error and browsers must use DOMException?

[syg]

What about abort the AC with an AbortCompletion?

What does AbortController have to do with this?

[Jack-Works]

What about abort the AC with an AbortCompletion?

What does AbortController have to do with this?

Oh it's typo, I mean abort the Abstract Operations.

[syg]

Oh it's typo, I mean abort the Abstract Operations.

Ah. I was thinking it'd just return some spec-internal value like ~not-handled~, telling the host it wasn't an ES value.

[ljharb]

What is node's use of structured cloning?

@Jack-Works yes, i mean exactly that.

[domenic]

Steps 19 and 20 will be refactored out, as they deal with non-ES values.

There are some substeps in the deep sections that also need a bit of care, e.g. StructuredSerializeInternal step 26.3.

All occurrences of "throw a "DataCloneError" DOMException" will be changed to "throw a host-defined exception".

My suggestion is that instead you use return values from the AO. So you can return either a JS value or ~failure~ which the host can translate as appropriate.

---

Another thing that might need slight tweaks is that object creation is not as precise as it should be in the current algorithms. E.g. HTML says

set value to a new Boolean object in targetRealm whose [[BooleanData]] internal slot value is serialized.[[BooleanData]].

which should probably be expanded to something like

1. Set value to ! OrdinaryCreateFromConstructor(targetRealm.[[Intrinsics]].[[%Boolean%]], "%Boolean.prototype%", « [[BooleanData]] »).
2. Set value.[[BooleanData]] to serialized.[[BooleanData]].

[andreubotella]

There could be platform objects deep into the object graph, so it seems like there would need to be host hooks for serializing and deserializing host objects, that get invoked in StructuredSerializeInternal and StructuredDeserialize. Perhaps if the serialization hook returns a record (as opposed to undefined or some spec-level empty marker), StructuredSerializeInternal would return a wrapped record with [[Type]]: "HostObject", to ensure that the deserialization hook can't affect built-ins.

[erights]

From https://html.spec.whatwg.org/#structuredserializeinternal step 13.2.1:

If the current settings object's cross-origin isolated capability is false

The settings object in question seems to be the [[HostDefined]] field of RealmRecords defined at https://tc39.es/ecma262/#realm-record . The ecma262 its internal structure is unspecified, and "cross-origin isolated capability" is not an EcmaScript concept. However, 13.2.1 goes on:

and a SharedArrayBuffer cannot leave an agent cluster.

which is a restriction meaningful, indeed necessary, in EcmaScript. This restriction needs rephrasing in purely EcmaScript terms and in a host independent manner.

[bathos]

Structured clone has some pretty unique behaviors which (afaik) aren't found elsewhere currently. Some of these amount to (very hard to leverage) unique information sources. The best known one is that it's the sole place where one can observe [[ErrorData]], but a more surprising one I think is that it bypasses IsArray and therefore uniquely pokes a hole in the boundary that (otherwise would) prevent ES code from observing whether an object is a true array exotic object.

I'd be curious to know if the quirky one-offs could be safely closed off (or whether folks would consider that desirable). I don't have much of an opinion on this; I'm just deeply fascinated by places where the unobservable becomes observable under a blood red moon and my god, structured clone delivers.

[erights]

pokes a hole in the boundary that (otherwise would) prevent ES code from observing

or whether folks would consider that desirable

I'm still absorbing. But IIUC, I find this both desirable and necessary. I left off the text after "observing" above because the concern is not specific to arrays. ANY case where this makes something observable that was previously unobservable is likely a bug that must be fixed. I look forward to going through cases. Thanks!

[erights]

https://html.spec.whatwg.org/#structuredserializeinternal step 17 refers to "platform object" which is not term used in ecma262. What does in mean in ecma262 terms? How would this be rephrased?