Initial pass at rewriting the structured clone algorithm #727

annevk · 2016-02-23T15:05:58Z

See https://html5.org/temp/structuredclone.html#safe-passing-of-structured-data for a more
reviewable version of this.

This is based on https://github.com/dslomov/ecmascript-structured-clone with changes to account for
changes in ECMAScript and feedback in #697.

This fixes #697 and also https://www.w3.org/Bugs/Public/show_bug.cgi?id=27031.

annevk · 2016-02-23T15:39:29Z

I would love review from @dslomov and @ajklein. @heycam might also want to take a look since this removes any IDL annotations for transferable objects, relying on prose instead.

Some xref'ing to ECMAScript might be broken/missing still. Would love to land #638 first since it puts down some more infrastructure for that.

Summary of changes:

Turn StructuredClone into an abstract operation that builds directly upon ECMAScript and takes a new targetRealm argument so objects are actually created in a place.
Move transfering into the StructuredClone abstract operation rather than as a special case in two different postMessage() algorithms.
Define a [[Clone]] internal method, [[Detached]] internal slot, and [[Transfer]] internal method for IDL-defined objects so they can participate in the fun.
Update all ECMAScript references to be ES6+-compatible.

I haven't used the new internal methods/slots for ECMAScript objects per @domenic's feedback. The preference was to have one giant monkey patch over lots of small ones (he worded this differently, see #697 ).

domenic · 2016-02-24T20:24:42Z

Hmm, this diff is unfortunate. Maybe it would be better with one commit that moves stuff around, then another that rewrites the structured clone section?

domenic · 2016-02-24T20:26:11Z

source

-   <li><p>Let <var>transfer map</var> be the <i>transfer map</i> passed to the algorithm, if any, or
-   the empty list otherwise.</p></li>
+  <p>IDL-defined objects must define the [[Clone]] internal method such that it either throws or
+  returns a copy of <b>this</b>, created in <var>targetRealm</var>.</p>


copy -> clone? Maybe add some sentence about how what "cloning" (or "copying") means is up to the object and what it thinks is best?

domenic · 2016-02-29T18:37:10Z

The problem is that the second sentence is not a complete sentence.

domenic · 2016-02-29T18:50:48Z

Last nits:

Let inputLen be OrdinaryGetOwnProperty(input, "length").[[Value]].

needs to become two steps so you can do !. I guess the temp variable would be inputLenDesc or something.

Let output be ArrayCreate(inputLen, outputProto).

needs !

LGTM otherwise, feel free to squash and merge with those fixed.

annevk · 2016-02-29T18:52:31Z

@domenic why would OrdinaryGetOwnProperty need !?

domenic · 2016-02-29T18:54:23Z

Because it returns a completion record and we need to show that it doesn't fail?

I guess ES is inconsistent about this; only one of its call sites does the explicit assert. Probably all of them should though...

annevk · 2016-02-29T18:55:33Z

It doesn't return a completion record though. It only ever returns a record or undefined, never a completion record. (I have a PR outstanding against ECMAScript to remove the existing ! usage.)

domenic · 2016-02-29T18:56:52Z

Hmm I was kind of under the impression that per https://tc39.github.io/ecma262/#sec-implicit-completion-values all abstract operations returned completion records, but OK, I guess it makes sense for this one to not do so.

annevk · 2016-02-29T18:57:20Z

Thanks (note that we have quite a bit of existing usage that does not use it either).

This is based on https://github.com/dslomov/ecmascript-structured-clone with changes to account for changes in ECMAScript and feedback in #697. This fixes #697 and also fixes https://www.w3.org/Bugs/Public/show_bug.cgi?id=27031. This should make it much more explicit how structured cloning actually works and also provides clear hooks for other standards to use to make their objects cloneable and transferable.

domenic · 2016-02-29T19:00:06Z

\o/

Fixes #981. Was introduced by #727 while rewriting part of the algorithm.

Fixes whatwg#981. Was introduced by whatwg#727 while rewriting part of the algorithm.

Currently attempting to transfer non-transferable objects using the structured clone algorithm throws a `TypeError`, rather than a `DataCloneError` `DOMException` as per the spec. This seems like a holdover from the original definition of transferable objects as the `Transferable` WebIDL type, since transfer lists would be defined as `sequence<Transferable>` and so would throw a `TypeError` on conversion. whatwg/html#727 changed transfer lists to be `sequence<object>` and changed the `StructuredCloneWithTransfer` algorithm (now `StructuredSerializeWithTransfer`) to throw a `DataCloneError` `DOMException` if any element in the transfer list is not transferable. Bug: 816447 Change-Id: I9f4f88a2d7a593766f394256606a688f299c7b57

Currently attempting to transfer non-transferable objects using the structured clone algorithm throws a `TypeError`, rather than a `DataCloneError` `DOMException` as per the spec. This seems like a holdover from the original definition of transferable objects as the `Transferable` WebIDL type, since transfer lists would be defined as `sequence<Transferable>` and so would throw a `TypeError` on conversion. whatwg/html#727 changed transfer lists to be `sequence<object>` and changed the `StructuredCloneWithTransfer` algorithm (now `StructuredSerializeWithTransfer`) to throw a `DataCloneError` `DOMException` if any element in the transfer list is not transferable. Bug: 816447 Change-Id: I9f4f88a2d7a593766f394256606a688f299c7b57 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3229544 Reviewed-by: Yuki Shiino <yukishiino@chromium.org> Reviewed-by: Kentaro Hara <haraken@chromium.org> Commit-Queue: Yuki Shiino <yukishiino@chromium.org> Cr-Commit-Position: refs/heads/main@{#934398}

… non-transferable objects, a=testonly Automatic update from web-platform-tests Throw `DataCloneError` when transferring non-transferable objects Currently attempting to transfer non-transferable objects using the structured clone algorithm throws a `TypeError`, rather than a `DataCloneError` `DOMException` as per the spec. This seems like a holdover from the original definition of transferable objects as the `Transferable` WebIDL type, since transfer lists would be defined as `sequence<Transferable>` and so would throw a `TypeError` on conversion. whatwg/html#727 changed transfer lists to be `sequence<object>` and changed the `StructuredCloneWithTransfer` algorithm (now `StructuredSerializeWithTransfer`) to throw a `DataCloneError` `DOMException` if any element in the transfer list is not transferable. Bug: 816447 Change-Id: I9f4f88a2d7a593766f394256606a688f299c7b57 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3229544 Reviewed-by: Yuki Shiino <yukishiino@chromium.org> Reviewed-by: Kentaro Hara <haraken@chromium.org> Commit-Queue: Yuki Shiino <yukishiino@chromium.org> Cr-Commit-Position: refs/heads/main@{#934398} -- wpt-commits: 4287b41333755fc3a4909a06ecb0780623c637fc wpt-pr: 31328

Currently attempting to transfer non-transferable objects using the structured clone algorithm throws a `TypeError`, rather than a `DataCloneError` `DOMException` as per the spec. This seems like a holdover from the original definition of transferable objects as the `Transferable` WebIDL type, since transfer lists would be defined as `sequence<Transferable>` and so would throw a `TypeError` on conversion. whatwg/html#727 changed transfer lists to be `sequence<object>` and changed the `StructuredCloneWithTransfer` algorithm (now `StructuredSerializeWithTransfer`) to throw a `DataCloneError` `DOMException` if any element in the transfer list is not transferable. Bug: 816447 Change-Id: I9f4f88a2d7a593766f394256606a688f299c7b57 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3229544 Reviewed-by: Yuki Shiino <yukishiino@chromium.org> Reviewed-by: Kentaro Hara <haraken@chromium.org> Commit-Queue: Yuki Shiino <yukishiino@chromium.org> Cr-Commit-Position: refs/heads/main@{#934398}

Currently attempting to transfer non-transferable objects using the structured clone algorithm throws a `TypeError`, rather than a `DataCloneError` `DOMException` as per the spec. This seems like a holdover from the original definition of transferable objects as the `Transferable` WebIDL type, since transfer lists would be defined as `sequence<Transferable>` and so would throw a `TypeError` on conversion. whatwg/html#727 changed transfer lists to be `sequence<object>` and changed the `StructuredCloneWithTransfer` algorithm (now `StructuredSerializeWithTransfer`) to throw a `DataCloneError` `DOMException` if any element in the transfer list is not transferable. Bug: 816447 Change-Id: I9f4f88a2d7a593766f394256606a688f299c7b57 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3229544 Reviewed-by: Yuki Shiino <yukishiino@chromium.org> Reviewed-by: Kentaro Hara <haraken@chromium.org> Commit-Queue: Yuki Shiino <yukishiino@chromium.org> Cr-Commit-Position: refs/heads/main@{#934398} NOKEYCHECK=True GitOrigin-RevId: ece66bb8e793ac03d11fe8f0b52f79bc1a030519

domenic self-assigned this Feb 23, 2016

domenic reviewed Feb 24, 2016
View reviewed changes

Move structured cloning out from under Common DOM Interfaces

e09b782

annevk force-pushed the structuredclone branch from 93d0a9a to 6b2644d Compare February 29, 2016 18:51

annevk force-pushed the structuredclone branch from 6b2644d to bfb960c Compare February 29, 2016 18:58

annevk merged commit bfb960c into master Feb 29, 2016

annevk deleted the structuredclone branch February 29, 2016 18:59

This was referenced Feb 29, 2016

Remove [[Class]] from structured clone #575

Closed

Clarify "for each enumerable own property" in structured clone #557

Closed

annevk mentioned this pull request Apr 2, 2016

Step 5 of MessagePort.postMessage doesn't make sense #981

Closed

annevk added a commit that referenced this pull request Apr 4, 2016

Editorial: else -> false in postMessage() algorithm

8abdb90

Fixes #981. Was introduced by #727 while rewriting part of the algorithm.

annevk mentioned this pull request Apr 4, 2016

Editorial: else -> false in postMessage() algorithm #986

Merged

domenic pushed a commit that referenced this pull request Apr 4, 2016

Editorial: else -> false in postMessage() algorithm

60e5fc3

Fixes #981. Was introduced by #727 while rewriting part of the algorithm.

jungkees pushed a commit to jungkees/html that referenced this pull request Apr 8, 2016

Editorial: else -> false in postMessage() algorithm

4cdf3a1

Fixes whatwg#981. Was introduced by whatwg#727 while rewriting part of the algorithm.

chromium-wpt-export-bot mentioned this pull request Oct 20, 2021

Throw DataCloneError when transferring non-transferable objects web-platform-tests/wpt#31328

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Initial pass at rewriting the structured clone algorithm #727

Initial pass at rewriting the structured clone algorithm #727

annevk commented Feb 23, 2016

annevk commented Feb 23, 2016

domenic commented Feb 24, 2016

domenic Feb 24, 2016

annevk Feb 25, 2016

domenic commented Feb 29, 2016

domenic commented Feb 29, 2016

annevk commented Feb 29, 2016

domenic commented Feb 29, 2016

annevk commented Feb 29, 2016

domenic commented Feb 29, 2016

annevk commented Feb 29, 2016

domenic commented Feb 29, 2016

Initial pass at rewriting the structured clone algorithm #727

Initial pass at rewriting the structured clone algorithm #727

Conversation

annevk commented Feb 23, 2016

annevk commented Feb 23, 2016

domenic commented Feb 24, 2016

domenic Feb 24, 2016

Choose a reason for hiding this comment

annevk Feb 25, 2016

Choose a reason for hiding this comment

domenic commented Feb 29, 2016

domenic commented Feb 29, 2016

annevk commented Feb 29, 2016

domenic commented Feb 29, 2016

annevk commented Feb 29, 2016

domenic commented Feb 29, 2016

annevk commented Feb 29, 2016

domenic commented Feb 29, 2016