Bug 102092 - Update DOMException name: HierarchyRequestError
Summary: Update DOMException name: HierarchyRequestError
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Erik Arvidsson
URL:
Keywords:
Depends on:
Blocks: 101606
  Show dependency treegraph
 
Reported: 2012-11-13 08:30 PST by Erik Arvidsson
Modified: 2012-11-13 22:58 PST (History)
5 users (show)

See Also:


Attachments
Patch (37.38 KB, patch)
2012-11-13 08:35 PST, Erik Arvidsson
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Erik Arvidsson 2012-11-13 08:30:52 PST
Update DOMException name: HierarchyRequestError
Comment 1 Erik Arvidsson 2012-11-13 08:35:58 PST
Created attachment 173902 [details]
Patch
Comment 2 Ojan Vafai 2012-11-13 09:08:43 PST
Comment on attachment 173902 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=173902&action=review

> Source/WebCore/dom/DOMCoreException.cpp:40
> +    { "HierarchyRequestError", "A Node was inserted somewhere it doesn't belong." },

Sigh. Not directly related to your patch, but this is not the most accurate error message. As in, the error below is a subset of this. It should probably be something like "Node cannot be inserted into one of it's ancestors." I'm not 100% sure we consistently only use it in this way, but we should. :)
Comment 3 Erik Arvidsson 2012-11-13 09:10:39 PST
(In reply to comment #2)
> (From update of attachment 173902 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=173902&action=review
> 
> > Source/WebCore/dom/DOMCoreException.cpp:40
> > +    { "HierarchyRequestError", "A Node was inserted somewhere it doesn't belong." },
> 
> Sigh. Not directly related to your patch, but this is not the most accurate error message. As in, the error below is a subset of this. It should probably be something like "Node cannot be inserted into one of it's ancestors." I'm not 100% sure we consistently only use it in this way, but we should. :)

The description of these are part of the standard too now. I plan to get to that in bug 101953
Comment 4 WebKit Review Bot 2012-11-13 10:02:48 PST
Comment on attachment 173902 [details]
Patch

Clearing flags on attachment: 173902

Committed r134435: <http://trac.webkit.org/changeset/134435>
Comment 5 WebKit Review Bot 2012-11-13 10:02:52 PST
All reviewed patches have been landed.  Closing bug.
Comment 6 Darin Adler 2012-11-13 10:26:26 PST
I suggest we also rename our internal HIERARCHY_REQUEST_ERR constant. The only reason it currently has the name it has is that we followed what was in the DOM specification.
Comment 7 Erik Arvidsson 2012-11-13 10:52:43 PST
(In reply to comment #6)
> I suggest we also rename our internal HIERARCHY_REQUEST_ERR constant. The only reason it currently has the name it has is that we followed what was in the DOM specification.

I'm not sure which internal constant you are referring to? The DOMException code property still reflects this numeric constant and the IDL file exposes constants for these.
Comment 8 Darin Adler 2012-11-13 12:25:44 PST
I’m mixed up here. I guess the name HIERARCHY_REQUEST_ERR still has relevance because it’s the name in the “name” property?
Comment 9 Erik Arvidsson 2012-11-13 13:11:57 PST
(In reply to comment #8)
> I’m mixed up here. I guess the name HIERARCHY_REQUEST_ERR still has relevance because it’s the name in the “name” property?

I understand this is confusing. The "name" property of the DOMExceptio is supposed to be "HierarchyRequestError". The "code" property will continue to be 3, which is also reflected as

const unsigned short HIERARCHY_REQUEST_ERR = 3;

in DOMCoreException.idl.

try {
  document.appendChild(document);
} catch (ex) {
  asssert(ex.name === "HierarchyRequestError");
  assert(ex.code === DOMException.HIERARCHY_REQUEST_ERR);
}

Does that resolve your concerns?
Comment 10 Darin Adler 2012-11-13 17:35:42 PST
Sure, kinda sad that there has to be both an ugly and non-ugly version of each name.
Comment 11 Csaba Osztrogonác 2012-11-13 22:58:01 PST
(In reply to comment #4)
> (From update of attachment 173902 [details])
> Clearing flags on attachment: 173902
> 
> Committed r134435: <http://trac.webkit.org/changeset/134435>

More expected update landed in http://trac.webkit.org/changeset/134549