12404 2011-03-31 06:51:38 +0000 Structured Clone and Arrays (implementation notes and clarifications sought) 2011-08-04 05:02:18 +0000 1 1 1 Unclassified HTML WG LC1 HTML5 spec unspecified PC Windows NT RESOLVED FIXED P2 normal LC 1 travil ian ayg bzbarsky ian jonas mike public-html-admin public-html-wg-issue-tracking travil public-html-bugzilla oldest_to_newest 47069 0 travil 2011-03-31 06:51:38 +0000 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. 47071 1 jonas 2011-03-31 07:56:58 +0000 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. 47074 2 bzbarsky 2011-03-31 13:51:58 +0000 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. 47174 3 travil 2011-04-06 00:08:45 +0000 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. 49805 4 ian 2011-06-17 21:14:31 +0000 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. 49843 5 travil 2011-06-18 19:47:12 +0000 Sounds good to me. Please also make sure to highlight the preservation of the array's length property for sparce arrays too. 50200 6 ian 2011-06-24 00:32:24 +0000 Done. 50201 7 contributor 2011-06-24 00:32:53 +0000 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 52526 8 mike 2011-08-04 05:02:18 +0000 mass-moved component to LC1