Bug 16637

Summary: Acid3 expects ExeceptionCode constants to be defined on DOMException objects
Product: WebKit Reporter: Eric Seidel (no email) <eric>
Component: DOMAssignee: Sam Weinig <sam>
Status: RESOLVED FIXED    
Severity: Normal CC: ap, cdumez, dstorey, sam
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Mac   
OS: OS X 10.4   
URL: http://www.hixie.ch/tests/evil/acid/003/NOT_READY_PLEASE_DO_NOT_USE.html
Attachments:
Description Flags
Add test case
none
An exceptional patch (HAR HAR HAR) darin: review+

Description Eric Seidel (no email) 2007-12-28 01:53:05 PST
Acid3 expect ExeceptionCode constants to be defined on DOMException objects

http://www.hixie.ch/tests/evil/acid/003/NOT_READY_PLEASE_DO_NOT_USE.html

    function () {
      // test 34: value of constants
      var e = null;
      try {
        document.body.appendChild(document.documentElement);
         // raises a HIERARCHY_REQUEST_ERR
      } catch (err) {
        e = err;
      }
      if ((document.DOCUMENT_FRAGMENT_NODE == 11) &&
          (document.body.COMMENT_NODE == 8) &&
          (document.createTextNode('').ELEMENT_NODE == 1) &&
          (e.HIERARCHY_REQUEST_ERR == 3) && (e.code == 3))
        return 3;
    },

We pass every part of that test, except for "e.HIERARCHY_REQUEST_ERR == 3"  e. HIERARCHY_REQUEST_ERR is not defined.

http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-17189187
Does not seem to agree with the test, but perhaps IE defines these constants on DOMException.
Comment 1 Alexey Proskuryakov 2007-12-28 07:22:07 PST
AFAICT, only Firefox does.  Firefox, Opera and WebKit all support DOMException.HIERARCHY_REQUEST_ERR (a constructor property).
Comment 2 Eric Seidel (no email) 2007-12-28 23:44:40 PST
Hixie has used the power of Appendix E to convince me.

Prototype Object DOMException
The DOMException class has the following constants:
DOMException.INDEX_SIZE_ERR
This constant is of type Number and its value is 1.

Since Node defines a similar "Prototype Object Node", we are to assume that those constants are to be defined on the prototype for DOMException, and thus available on all DOMException instances.
Comment 3 Eric Seidel (no email) 2007-12-28 23:45:09 PST
Sadly, JSDOMException is not autogenerated (i'm not even sure it exists) otherwise this would be easy.
Comment 4 Eric Seidel (no email) 2007-12-29 00:06:43 PST
Created attachment 18167 [details]
Add test case

 .../fast/dom/DOMException/prototype-object.html    |   13 +++++++++++++
 .../fast/dom/DOMException/resources/TEMPLATE.html  |   13 +++++++++++++
 .../dom/DOMException/resources/prototype-object.js |   15 +++++++++++++++
 WebCore/WebCore.xcodeproj/project.pbxproj          |    1 +
 4 files changed, 42 insertions(+), 0 deletions(-)
Comment 5 Eric Seidel (no email) 2007-12-29 00:08:35 PST
Firefox passes this test case, we fail, opera fails too.
Comment 6 Sam Weinig 2007-12-31 15:55:46 PST
Created attachment 18219 [details]
An exceptional patch (HAR HAR HAR)
Comment 7 Darin Adler 2007-12-31 16:06:08 PST
Comment on attachment 18219 [details]
An exceptional patch (HAR HAR HAR)

+        // FIXME: this is copied from ExceptionCode.h, it needs to be kept in sync.

And both need to be kept in sync with the standard! Why can't DOMCoreException use the values from ExceptionCode.h -- it includes that file, so it should be able to. Can we change things later so these are defined only in the .idl file?

What about non-core errors?

Can we make sure the name "DOMCoreException" doesn't show through in JavaScript?

+shouldBeEqualToString("e.constructor.toString()", "[object DOMCoreExceptionConstructor]");

That should be "[object DOMExceptionConstructor]" -- we don't want to expose the naming conflict issues in WebKit to the web content.

r=me
Comment 8 Sam Weinig 2007-12-31 19:04:44 PST
Landed in r29058.
Comment 9 Lucas Forschler 2019-02-06 09:02:38 PST
Mass moving XML DOM bugs to the "DOM" Component.