This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 12221 - Should Structured Clone preserve property descriptors?
Summary: Should Structured Clone preserve property descriptors?
Status: CLOSED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 normal
Target Milestone: LC
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-03-02 18:35 UTC by Travis Leithead [MSFT]
Modified: 2011-08-04 05:11 UTC (History)
6 users (show)

See Also:


Attachments

Description Travis Leithead [MSFT] 2011-03-02 18:35:39 UTC
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
Comment 1 Ian 'Hixie' Hickson 2011-05-05 21:31:28 UTC
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.
Comment 2 contributor 2011-05-05 21:32:11 UTC
Checked in as WHATWG revision r6085.
Check-in comment: clarification
http://html5.org/tools/web-apps-tracker?from=6084&to=6085
Comment 3 Michael[tm] Smith 2011-08-04 05:11:43 UTC
mass-move component to LC1