12221 2011-03-02 18:35:39 +0000 Should Structured Clone preserve property descriptors? 2011-08-04 05:11:43 +0000 1 1 1 Unclassified HTML WG LC1 HTML5 spec unspecified PC Windows NT CLOSED FIXED P2 normal LC 1 travil ian ayg ian mike public-html-admin public-html-wg-issue-tracking travil public-html-bugzilla oldest_to_newest 46189 0 travil 2011-03-02 18:35:39 +0000 I propose that when cloning properties, the cloned properties be "fresh" properties such that previous modifications to the ECMAScript 5 property descriptors are not preserved (just take the defaults). I take this approach because it seems simpler, but I'm open to other points of view. In step 5 of the internal structured clone algorithm, we have the following text: 5.If input is an Array object or an Object object, then, for each enumerable property in input, add a corresponding property to output having the same name, and having a value created from invoking the internal structured cloning algorithm recursively with the value of the property as the "input" argument and memory as the "memory" argument. The order of the properties in the input and output objects must be the same. The key phrase of interest is: "add a corresponding property to output having the same name" In the world of ECMAScript 5, properties have additional "property descriptors" such as configurable, writable, getters and setters. The question I have is when the algorithm says to "add a corresponding property" does it expect to preserve the property descriptors of the source property? For example, I wonder whether a source property with configurable: false, and writable: false attributes would be created on the cloned object with those same attributes, or whether they would default back to configurable: true and writable: true? The algorithm is specific about the enumerable attribute--only enumerable: true properties are considered for the clone. Finally, I wouldn't expect to preserve the getter and setter functions as those functions shouldn't be allowed through the cloning process--also there's a pre-existing bug on a potential recursion issue in bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=12101 48106 1 ian 2011-05-05 21:31:28 +0000 EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: see diff given below Rationale: I've replaced the word "corresponding" with "new" to remove the ambiguity, and added a non-normative paragraph that explains this. Hopefully that's ok. 48107 2 contributor 2011-05-05 21:32:11 +0000 Checked in as WHATWG revision r6085. Check-in comment: clarification http://html5.org/tools/web-apps-tracker?from=6084&to=6085 53231 3 mike 2011-08-04 05:11:43 +0000 mass-move component to LC1