1.4.8: angular copy looses object type

[slepkaviba]

When an object contains a property initialized with new String() it is not serialized properly into the string using JSON.stringify if angular.copy() was used on it. Example on plunkr:

http://plnkr.co/edit/QzHZcJExzbdynqwt8TWh?p=preview

So:

  var str = new String('test');
  var obj = {
    test: str
  };

  JSON.stringify(obj) !== JSON.stringify(angular.copy(obj));

I have checked with lodash clone and angular's extend, and there all seems fine.

Issue seems tricky in a way that ngOptions seems to .copy() values, so that instead of strings there, we are receiving map of letters in the model.

[lgalfaso]

There are a few built-in objects that copy does not handle properly. There are a few open issues to track several different cases, but I think it would make more sense to track them all in one issue. The built-in objects that need special treatment and are not handled properly are, AFAIK:

• String
• Number
• Boolean
• ArrayBuffer
• DataView
• ES6 collections

[Narretz]

Do we want to fix all of these? Will it make copy slower?

edit: We probably should, since these objects can occur in watches etc.

[lgalfaso]

@Narretz my opinion is that we should fix String, Number, Boolean and ArrayBuffer, but I wrote the entire list so people can comment here

[slepkaviba]

This bugs are very tricky. And as they are not often they can mess up some things very badly. I think that even impact on copy performance (deep copy doesn't have to be fast, right?) it should be reliable.

[jbedard]

I've opened a PR String/Number/Boolean and another for ArrayBuffer. I'd say may as well also do DataView and ES6 collections as well though...

[wesleycho]

Given the desired changes landed for copy, this issue can probably be closed.

[Narretz]

Yes, the original issue is fixed in 1.5.x. Support for other data types can be added later if it is requested.