18362 2012-07-23 14:18:20 +0000 Make stringifiers not take into account expandos 2014-02-03 21:42:04 +0000 1 1 1 Unclassified WebAppsWG WebIDL unspecified All Windows 3.1 RESOLVED FIXED [v1] P2 normal --- 1 Ms2ger cam bzbarsky mike public-script-coord travil public-webapps-bugzilla oldest_to_newest 71313 0 Ms2ger 2012-07-23 14:18:20 +0000 See <http://w3c-test.org/html/tests/submission/Ms2ger/the-elements-of-html/text-level-semantics/the-a-element/a-stringifier.html> for a test. I think it makes more sense to directly call the real implementation rather than to pay attention to random properties scripts put on the object; this would also match current implementations. 79792 1 cam 2012-12-10 04:43:35 +0000 I don't know, I tend to think that for example interface Blah { stringifier readonly attribute DOMString something; }; means Object.defineProperty(Blah.prototype, "something", { get: function() { return <internal state>; }, ...); Blah.prototype.toString = function() { return this.something; } rather than Object.defineProperty(Blah.prototype, "something", { get: function() { return <internal state>; }, ...); Blah.prototype.toString = function() { return <internal state>; } and I feel like it is a more natural way of implementing it. It's in line with what we're doing for [PutForwards], too. 79796 2 bzbarsky 2012-12-10 05:07:08 +0000 > and I feel like it is a more natural way of implementing it. Is that compatible with what happens on the DOM objects that have stringifiers right now (like HTMLAnchorElement, say)? 79798 3 cam 2012-12-10 05:11:47 +0000 (In reply to comment #2) > Is that compatible with what happens on the DOM objects that have > stringifiers right now (like HTMLAnchorElement, say)? var a = document.createElement("a"); a.setAttribute("href", "no:"); Object.defineProperty(a, "href", { value: "yes" }); alert(a) says no... 79807 4 bzbarsky 2012-12-10 06:00:04 +0000 > says no... In which browsers, just to check? But given that, reopening... I'm not sure I want the compat can of worms of changing how <a> behaves. 79808 5 cam 2012-12-10 06:04:28 +0000 (In reply to comment #4) > In which browsers, just to check? In Firefox, Chrome and Opera. > But given that, reopening... I'm not sure I want the compat can of worms of > changing how <a> behaves. All right. I figured it was not going to be likely that people would be redefining/overriding .href with ES5 stuff, but I'll defer to your judgement of how many worms there are in that can. :) 79810 6 bzbarsky 2012-12-10 06:07:33 +0000 Worth checking Safari and IE too, I bet. As for number of worms... Maybe I'm overworrying this. I'd love feedback from other implementors on how happy they are to change this behavior. 79811 7 bzbarsky 2012-12-10 06:09:25 +0000 Oh, one other note. Right now, anonymous stringifiers _do_ return <internal state>, so even if stringifiers keep on seeing expandos we could make <a> work: it would have to use an anonymous stringifier defined in prose to return the same thing as href. 79859 8 travil 2012-12-10 20:38:36 +0000 IE10 fails tests 2&3, 6&7 with the following: assert_throws: function "function() { aObject.toString(); }" did not throw 91569 9 cam 2013-08-03 07:34:35 +0000 We no longer delegate using [[Get]] and [[Call]], and instead just run whatever prose the operation/attribute defines. http://dev.w3.org/cvsweb/2006/webapi/WebIDL/Overview.xml.diff?r1=1.663;r2=1.664;f=h http://dev.w3.org/cvsweb/2006/webapi/WebIDL/v1.xml.diff?r1=1.104;r2=1.105;f=h 99642 10 Ms2ger 2014-02-03 21:42:04 +0000 https://github.com/w3c/web-platform-tests/pull/599