This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In some recent testing of structured cloning across various browsers using Arrays, we found some de-facto conformity that diverges from a literal interpretation of the spec text of step 5 of the _internal structured cloning algorithm_ (section 2.8.5). We're proposing some clarifying text be added to the spec. ----- a = ["zero","one"]; a.foo = "bar"; Clarifiction 1: Per step 5 of the algorithm, an implementation should clone "each enumerable property". In the example, a has 3 enumerable properties, but in all browsers tested only the properties "0" and "1" (and their values) were cloned. We propose that this section have a special section for Array objects and note that only the index properties of the array be cloned. Clarification 2: a.length = 4; Now the Array a has a length of 4, but only two entries (a sparce-array). In all browsers tested (with the exception of Safari 5), only the first two entries in the array were cloned. The length of the resultant clone was truncated to the last non-null/undefined value in the array (2). We propose that sparce-arrays likewise be "clipped" to the last non-null/undefined value, or that the behavior for sparce-arrays be otherwise more clearly described in the algorithm.
I think we should treat these as bugs in existing implementations. If these problems exist in Firefox (note that we currently only use the structured clone algorithm in worker.postMessage), then we should and will fix them. Especially the second point in comment 0 seems like a dangerous change to make to the structured data. I definitely think that would cause author bugs and confusion.
Indeed. In particular, the given description of clarification 2 is manifestly incorrect, as it doesn't differentiate between these two arrays: ["zero", "one", undefined, undefined] ["zero", "one", , , ] which are both arrays of length 4; the former is dense but the latter is sparse. That said, I believe that this part of the behavior is correct, given what the spec says right now: the second array above, as well as the array in your example, only has two enumerable properties: "0" and "1". I agree that for arrays it would make sense to clone the length as well, even though it's not enumerable.
Based on this feedback, it looks like the general consensus (which I agree with) is that: 1. Any enumerable "own" property on an array should be cloned (this does not require a spec change, as the current wording implies that this should happen for Object/Arrays) 2. The length of a sparce-array should be preserved when cloning. This requirement will necessitate a small spec change to alert implementors of this condition.
I can add some non-normative text to cover both of these, and some examples, assuming we're indeed ok with the basic requirements already in the spec.
Sounds good to me. Please also make sure to highlight the preservation of the array's length property for sparce arrays too.
Done.
Checked in as WHATWG revision r6274. Check-in comment: Structured clone: Preserve sparse arrays and mention that non-index properties of arrays are preserved too. http://html5.org/tools/web-apps-tracker?from=6273&to=6274
mass-moved component to LC1