362571 - Some DOM methods throw inappropriate exceptions when passed null or undefined (NS_ERROR_INVALID_POINTER)

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[David "liorean" Andersson]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0

Currently a few DOM methods (e.g. appendChild, removeChild, replaceChild) raise NS_ERROR_INVALID_POINTER exceptions if given an argument that is not a node (e.g. null, undefined).
I think this exception is wonderfully inappropriate as pointers are an implementation detail and can't be found as constructs in either the DOM API or in ECMAScript, and it's an error that confuses many developers trying to debug their code, instead of a more detailed argument that actually applies to their programming environment.
A more appropriate error would be some DOM error (not sure which, TYPE_MISMATCH_ERR seems like the obvious candidate, but INVALID_ACCESS_ERR and NOT_SUPPORTED_ERR also seem like they could apply). Or maybe an ECMAScript TypeError with a message somewhat like this: "Invalid Argument: Argument {argumentname} to {objecttype}.{methodname} must be a Node object.".

Reproducible: Always

Steps to Reproduce:
1. Run "javascript:document.documentElement.appendChild(undefined);"
2. Check the error console:
uncaught exception: [Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsIDOMHTMLHtmlElement.appendChild]" nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)" location: "JS frame :: javascript:document.documentElement.appendChild(undefined); :: <TOP_LEVEL> :: line 1" data: no]
Actual Results:  
NS_ERROR_INVALID_POINTER is appropriate for C/C++ code, but not for JavaScript. The error is not the least helpful for JavaScript debugging and should be replaced by an appropriate error instead. It may even scare away some developers from finding the right solution since they have no idea what NS_ERROR_INVALID_POINTER means in a JavaScript context and the error message look like the error lies in application code and not in their script.

Comment 1

[Jesse Ruderman]

This confused the reporter of bug 258463, too.  I agree that the "invalid pointer" message is confusing and scary.

Comment 2

[Markus Koller]

Uhmm yes, bump?

I've seen these errors every now and then and always just assumed they were caused by buggy extensions, and so ignored them. But now that I've started logging client-side JavaScript exceptions I've noticed them in my own code, and finally found an explanation in this bug report.

The error message is still confusing and inappropriate, it would be great if someone could take the time to improve it.


User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.7) Gecko/20100721 Iceweasel/3.6.7 (like Firefox/3.6.7)

Comment 3

[Zack Weinberg (:zwol)]

For insertion, it looks to me that DOM4 now actually specifies the error code that should be generated: http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#mutation-algorithms - steps 4.1 and 5 of the "pre-insert" algorithm both read "If node is not a DocumentFragment, DocumentType, Element, ProcessingInstruction, or Comment node, throw a "HierarchyRequestError" and terminate these steps."

I would make the broader claim that if unprivileged JS *ever* gets "Component returned failure code:" that is a bug.

Comment 4

[Masatoshi Kimura [:emk]]

Per Web IDL, ECMAScript TypeError would be thrown for appendChild(undefined) before invoking the "pre-insert" algorithm.
http://dev.w3.org/2006/webapi/WebIDL/#es-interface

Comment 5

[Boris Zbarsky [:bzbarsky]]

Fixed by bug 812333:

[11:02:20.802] document.documentElement.appendChild(undefined)
[11:02:20.816] TypeError: Value not an object.

Comment 6

[Zack Weinberg (:zwol)]

Shouldn't it be HierarchyRequestError, not TypeError, per DOM4 (see comment 3)?

Comment 7

[Masatoshi Kimura [:emk]]

http://dev.w3.org/2006/webapi/WebIDL/#es-interface
> 1. If Type(V) is not Object, then throw a TypeError.
This conversion is executed before appendChild see the parameter, so it can't throw HierarchyRequestError.

Comment 8

[Masatoshi Kimura [:emk]]

..and I had already said it in comment #4.