28389 2015-04-01 11:58:57 +0000 Allow error objects to be structured-clonable 2016-03-16 14:00:04 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED WONTFIX P3 normal Unsorted 1 jaffathecake ian adamk annevk bugs d ian jaffathecake mike zcorpan contributor oldest_to_newest 119172 0 jaffathecake 2015-04-01 11:58:57 +0000 Use case: A page postMessages a worker to request a particular task be completed. That tasks fails, the worker wishes to post back the error. The cloned error could be constructed using the message of the original. 119328 1 ian 2015-04-07 22:38:05 +0000 The concern is that Error objects could include sensitive data (like a stack trace). But in principle I don't disagree. IIRC the JS spec is going to eventually define structure cloning, so maybe I'll punt til that. 119348 2 zcorpan 2015-04-08 10:27:52 +0000 We don't protect any sensitive data by not supporting cloning of Errors, since you can just create a new plain object with the properties copied from the Error, and send that. 119412 3 ian 2015-04-09 20:19:29 +0000 It's more accidental transfers that I would be concerned about. Obviously if someone is just sending the data across intentionally there's not much we can do. 125292 4 annevk 2016-02-29 10:19:39 +0000 Adam, Olli, opinions? 125293 5 d 2016-02-29 13:04:00 +0000 I would like to do a TC39 proposal to make Error objects completely non-exotic (by removing the almost-entirely-unused [[ErrorData]] object). If that happens then they should become automatically structured-clonable. That doesn't really impact DOMException though, which is exotic in its own ways. 125297 6 d 2016-02-29 19:47:19 +0000 I submitted a PR to TC39 for discussion here to make Error objects non-exotic: https://github.com/tc39/ecma262/pull/438 However, I realized this approach might actually be counterproductive to our purposes here. See discussion in that thread. 125331 7 adamk 2016-03-03 01:52:21 +0000 I don't feel like I have a horse in this race; I can't say I really understand the hazard here. 125427 8 bugs 2016-03-10 10:24:44 +0000 This feels like an edge case. Would someone really pass error object to the other side of postMessage? (that is I guess really the only even vaguely reasonable use case for error in sc. Storing it in history state or notification or elsewhere doesn't make much sense.) I agree with Hixie's comment 1 and comment 3. I'm a bit worried about accidentally passing sensitive data. And really, is there a proper use case for this? But I don't strongly object making error object structured-clonable. 125428 9 annevk 2016-03-10 10:30:08 +0000 FWIW, I tried to work through how this would work in terms of ECMAScript and couldn't quite figure it out. As far as I can tell there's no reliable way to get the name of a constructor of an Error object in ECMAScript so it's not quite clear to me how to clone it without making changes to ECMAScript proper. 125520 10 annevk 2016-03-16 14:00:04 +0000 Closing this since I don't really have a good idea as to how this could work and nobody seems super compelled to have a go at it. Please don't hesitate to file a GitHub issue with a concrete proposal though. Or let me know if you think I'm wrong here.