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 26384 - Structure cloning Map and Set objects: what should get cloned?
Summary: Structure cloning Map and Set objects: what should get cloned?
Status: RESOLVED MOVED
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL:
Whiteboard: blocked waiting for JS spec to define...
Keywords:
Depends on:
Blocks:
 
Reported: 2014-07-18 19:23 UTC by Tom Schuster
Modified: 2016-02-29 21:24 UTC (History)
6 users (show)

See Also:

Attachments

Description Tom Schuster 2014-07-18 19:23:44 UTC 
I would like to have a confirmation that cloning the "object properties" on Map and Set is really intentional. I don't think that is particularly useful behavior.

In my first (non-specification based) implementation I didn't even consider that possibility. https://bugzilla.mozilla.org/show_bug.cgi?id=1036136
Comment 1 Jason Orendorff 2014-07-18 19:27:18 UTC 
It's also a little surprising because the spec doesn't clone expando properties of Dates or Arrays. Always cloning expandos would at least be consistent.
Comment 2 Ian 'Hixie' Hickson 2014-07-19 16:46:26 UTC 
The current text is more or less a placeholder. I expect eventually the cloning of native JS types to be defined in JS proper.
Comment 3 Bobby Holley (:bholley) 2014-08-15 00:37:11 UTC 
With my security hat on, I would vastly prefer to not clone expandos (and only do so for Object and Array). I can explain why if needed, but it sounds like nobody's really in disagreement here.
Comment 4 Adam Klein 2015-05-19 21:14:00 UTC 
The current spec text is in terms of [[MapData]] and [[SetData]], which looks correct to me. Should this issue be marked as resolved?
Comment 5 Anne 2015-08-28 15:41:13 UTC 
Indeed.
Comment 6 Anne 2016-02-29 21:24:51 UTC 
The text was indeed wrong and is unfortunately still wrong. This is now https://github.com/whatwg/html/issues/754 and I hope to fix it soon.