Clarify "for each enumerable own property" in structured clone

[shvaikalesh]

Please, see internal structured cloning algorithm, step 8:

for each enumerable own property in input

Should it invoke [[OwnPropertyKeys]] and filter by enumerability (and copy properties with symbols as keys) or just call EnumerableOwnNames?

I have tested the algorithm in Safari 9, Chrome 47 and Firefox 46 and it seems they are doing EnumerableOwnNames.

[domenic]

There are a few differentiating features between the two choices:

• In the rare instance someone chose to explicitly define an enumerable symbol-named property, should it be included? (EnumerableOwnNames says no)
  • Relatedly, if the key is a Symbol, should [[GetOwnProperty]] be triggered or no? Observable by proxies. (EnumerableOwnNames says no.)
• Should the order be for-in order, or the well-defined order given by [[OwnPropertyKeys]]? (EnumerableOwnNames says for-in order)

@ajklein, any comments? It sounds like we should just spec EnumerableOwnNames.

[shvaikalesh]

Should the order be for-in order, or the well-defined order given by [[OwnPropertyKeys]]? (EnumerableOwnNames says for-in order)

Correct me if I am wrong, but for in calls [[Enumerate]] which calls [[OwnPropertyKeys]]. They both sort the output keys in the same well-defined way.

[domenic]

(Please stop linking to the outdated spec; use https://tc39.github.io/ecma262/.)

[[Enumerate]] does obtain its keys "as if by calling its [[OwnPropertyKeys]] internal method", but the ordering it returns them in is implementation-defined: "The mechanics and order of enumerating the properties is not specified but must conform to the rules specified below."

[shvaikalesh]

The mechanics and order of enumerating the properties is not specified but must conform to the rules specified below.

Sorry, missed that.

Regarding proxies: structured clone throws on Proxies in Firefox. This may be related to #575.

[annevk]

Fixed by #727.

@shvaikalesh my apologies for not asking you for review while working on that PR. Review of the revived algorithm that is in terms of the current ECMAScript standard would be most welcome.

[domenic]

Hmm it appears actually #727 changed things to be all own string properties, eliminating the enumerable qualifier :-/. That is probably bad?

[annevk]

Isn't that what implementations actually do though?

[annevk]

Run

<script>
 var y = { test: "TEST" }
 x = Object.create(y)
 w(x)
 onmessage = e => w(e.data)
 postMessage(x, "*")
</script>

in Live DOM Viewer. First logs x having one property, then zero.

[domenic]

That's not enumerability you're testing; that's own-ness.

https://jsbin.com/radumu/edit?html,output shows that non-enumerable properties are not copied. Whereas in the new spec they are.

It seems like you need a check. I'll work on a quick PR.

[annevk]

Fair. (Not around to review, will land tomorrow.)