Added a proxy test case. Firefox and Edge again throw a DataCloneError, and this time Chrome outputs an empty object, ignoring the own property. The spec currently requires the DataCloneError per:

Otherwise, if input is an exotic object, then throw a DataCloneError exception.

Should we keep [[Transfer]] inconsistent and only exposed on objects annotated as transferable objects? (This is why I initially wanted to give all objects these internal methods. Implications would be more obvious and new objects would automatically throw unless specified otherwise.)

I don't think there's a need to be consistent there. Transfer doesn't have a fallback case, so it's very different from cloning in terms of who needs to define what. If we gave all objects these internal methods, that wouldn't change things either; the fallback case would still apply to new objects, unless they were defined to explicitly override the default own-properties [[Clone]].

That was the idea. By default [[Clone]] would throw and each object that wants to partake defines its own.

That can't work, because that will break the own-properties cloning of ordinary objects.

Good point.

Any object with internal slots that we don't otherwise handle throws a DataCloneError. This can remove some existing steps and future-proofs us against new ES types.

How would you word this? My thought was to just block them explicitly.

I would probably literally say "Otherwise, if input has any internal slots, then throw a DataCloneError exception." You could then remove step 17 for [[ErrorData]]. I guess this would go after the current step 19.

It seems like some sort of implementation strategy mismatch TBH.

I'd guess Edge and Firefox are checking if the object has any private data stored on it (using implementation-specific mechanisms for doing that), and if so throwing a DataCloneError. So that goes with the "anything with internal slots" approach. Whereas Chrome is explicitly blocklisting certain things (like Errors), corresponding to the explicit list of blocklisted internal slots.

Maybe @ajklein can comment on whether the "has any internal slots" approach is feasible for Chrome.

For the record, @annevk and I spelunked through Firefox's implementation a bit. Key lines are:

• https://mxr.mozilla.org/mozilla-central/source/js/src/jsfriendapi.cpp#267 which sets an object's "JS class" to "Object" if it's a "plain object"
• https://mxr.mozilla.org/mozilla-central/source/js/src/vm/StructuredClone.cpp#1178 which keys off of that to do the own-property cloning instead of saying unsupported

This notion of "plain object" isn't something terribly well supported by the ES spec, but maybe "has no internal slots" is a good proxy for it. (In ES5 it was taken care of by [[Class]] being Object.)

Paging @ajklein for opinions. Our plan here is to align with Edge and Firefox.

Not sure what you mean by "feasible". Any choice here should be implementable. Mostly Chrome's behavior can be explained by the fact that the structured clone code is in Blink and the new ES object code is in V8. So it's really a matter of what we'd like to say in the spec. From that point of view, I guess it's more concise to say "has internal slots" (though I don't know how that interacts with, say, the private state proposal).