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 18362 - Make stringifiers not take into account expandos
Summary: Make stringifiers not take into account expandos
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: WebIDL (show other bugs)
Version: unspecified
Hardware: All Windows 3.1
: P2 normal
Target Milestone: ---
Assignee: Cameron McCormack
QA Contact: public-webapps-bugzilla
URL:
Whiteboard: [v1]
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-23 14:18 UTC by Ms2ger
Modified: 2014-02-03 21:42 UTC (History)
4 users (show)

See Also:

Attachments

Description Ms2ger 2012-07-23 14:18:20 UTC 
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.
Comment 1 Cameron McCormack 2012-12-10 04:43:35 UTC 
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.
Comment 2 Boris Zbarsky 2012-12-10 05:07:08 UTC 
> 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)?
Comment 3 Cameron McCormack 2012-12-10 05:11:47 UTC 
(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...
Comment 4 Boris Zbarsky 2012-12-10 06:00:04 UTC 
> 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.
Comment 5 Cameron McCormack 2012-12-10 06:04:28 UTC 
(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. :)
Comment 6 Boris Zbarsky 2012-12-10 06:07:33 UTC 
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.
Comment 7 Boris Zbarsky 2012-12-10 06:09:25 UTC 
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.
Comment 8 Travis Leithead [MSFT] 2012-12-10 20:38:36 UTC 
IE10 fails tests 2&3, 6&7 with the following:

assert_throws: function "function() { aObject.toString(); }" did not throw
Comment 9 Cameron McCormack 2013-08-03 07:34:35 UTC 
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