(In reply to comment #0)
> Object.prototype.isPrototypeOf(DOMException.prototype) is true in all browsers
> (IE9, Firefox 11a1, Chrome 17 dev, Opera 12.00).  4.9.2 in the spec says it
> should be Error.prototype, not Object.prototype.  If the spec is changed to
> match browsers here, .toString needs to be defined on the prototypes, and
> possibly .message as well.

Object.getPrototypeOf(Error.prototype) === Object.prototype

So, toString will already be available.

.message is already defined on Error.prototype (it's the empty string).

Sorry if I wasn't clear.  In browsers, DOMException inherits from Object in the prototype chain, not Error.  Thus there's no .message inherited from Error.  Likewise, there's no .toString inherited from Error -- it's inherited from Object, which has a different .toString:

Object.prototype.toString: http://es5.github.com/#x15.2.4.2
Error.prototype.toString: http://es5.github.com/#x15.11.4.4

So I see two possibilities:

1) This bug is closed WONTFIX.  The spec is left as-is, which contradicts all browsers, and browsers are asked to change.  I'm fine with this, but only if browsers are actually willing to change.

2) The spec is changed to say that exception types like DOMException inherit from Object rather than Error, to match browsers.  In this case, the spec needs to require that .toString and possibly .message be defined on all exception interface prototype objects, because they will no longer be inherited from Error, and the ones inherited from Object don't behave in the expected fashion ({}.toString() on a DOMException gives "[object DOMException]" instead of the .message).

(In reply to comment #2)
> Sorry if I wasn't clear.  In browsers, DOMException inherits from Object in the
> prototype chain, not Error.  Thus there's no .message inherited from Error. 
> Likewise, there's no .toString inherited from Error -- it's inherited from
> Object, which has a different .toString:
> 
> Object.prototype.toString: http://es5.github.com/#x15.2.4.2
> Error.prototype.toString: http://es5.github.com/#x15.11.4.4

Oh, I didn't even realise Error has its own toString.

> So I see two possibilities:
> 
> 1) This bug is closed WONTFIX.  The spec is left as-is, which contradicts all
> browsers, and browsers are asked to change.  I'm fine with this, but only if
> browsers are actually willing to change.
> 
> 2) The spec is changed to say that exception types like DOMException inherit
> from Object rather than Error, to match browsers.  In this case, the spec needs
> to require that .toString and possibly .message be defined on all exception
> interface prototype objects, because they will no longer be inherited from
> Error, and the ones inherited from Object don't behave in the expected fashion
> ({}.toString() on a DOMException gives "[object DOMException]" instead of the
> .message).

Is this issue here the prototype or the stringification?  I think we want to keep the prototype change, as part of the new exception model.

If it is necessary that DOMExceptions get stringified to "[object DOMException]" then we could stick a stringifier on DOMException (and change Web IDL to allow stringifiers on exceptions).

This is what browser do currently for a HIERARCHY_REQUEST_ERR DOMException:

* Firefox: '[Exception... "Node cannot be inserted at the specified point in the hierarchy" code: "3" nsresult: "0x80530003 (NS_ERROR_DOM_HIERARCHY_REQUEST_ERR)" location: "blah"]'
* Opera: 'DOMException: HIERARCHY_REQUEST_ERR'
* Safari/Chrome: 'Error: HIERARCHY_REQUEST_ERR: DOM Exception 3'
* IE: 'DOM Exception: HIERARCHY_REQUEST_ERR (3)'

So there's a bit of variety there.

(In reply to comment #3)
> Is this issue here the prototype or the stringification?  I think we want to
> keep the prototype change, as part of the new exception model.

That's fine by me.  Then no spec change is needed AFAICT.  I've changed the tests to match the spec instead of browsers:

http://dvcs.w3.org/hg/html/rev/f06e5627c826

> This is what browser do currently for a HIERARCHY_REQUEST_ERR DOMException:
> 
> * Firefox: '[Exception... "Node cannot be inserted at the specified point in
> the hierarchy" code: "3" nsresult: "0x80530003
> (NS_ERROR_DOM_HIERARCHY_REQUEST_ERR)" location: "blah"]'
> * Opera: 'DOMException: HIERARCHY_REQUEST_ERR'
> * Safari/Chrome: 'Error: HIERARCHY_REQUEST_ERR: DOM Exception 3'
> * IE: 'DOM Exception: HIERARCHY_REQUEST_ERR (3)'
> 
> So there's a bit of variety there.

That's partly because DOM4 leaves the value of .message undefined, although also partly because browsers don't agree on what .name should be and/or don't follow ES5's Error.prototype.toString().