16591 - createElement() with space in name throws no/wrong exception

Status: VERIFIED DUPLICATE of bug 16603

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

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

DESCRIPTION:  Calling document.createElement(" blah")  [note the space!] should
throw the INVALID_CHARACTER_ERR exception.  Instead:
 * In HTML, it throws NS_ERROR_NOT_AVAILABLE
 * In XML, it does not throw an exception

STEPS TO REPRODUCE (HTML):
 * Load http://www.fas.harvard.edu/~dbaron/dom/test/one-core-html/exceptions
 * Hit "test" button

STEPS TO REPRODUCE (XML):
 * Load http://www.fas.harvard.edu/~dbaron/dom/test/one-core-xml/exceptions
 * Hit "test" button

ACTUAL RESULTS:
 * In XML, the first test output line (line that is red or green) says that it
didn't throw an exception, but instead returned [object Element]
 * In HTML, it gives a red output line describing the exception that it did
throw.

EXPECTED RESULTS:
 * The first output line (the one below
   'Trying document.createElement(" blah")') should be green.

DOES NOT WORK CORRECTLY ON:
 * Linux, viewer, 1999-10-15-11-M11

Comment 1

[vidur (gone)]

In an attempt to get my bug list in order again, marking all the bugs I have
currently as ASSIGNED.

Comment 2

[buster]

I think the solution for this is simply to have DocumentCreateElement in
nsJSDocument.cpp map the parser result NS_ERROR_NOT_AVAILABLE (which means the
parser identified the string as not being a legal HTML tag) to
NS_ERROR_DOM_INVALID_CHARACTER_ERR.  I won't bother with a patch because the
code is so trivial.

Comment 3

[jst]

Buster, I don't like that because a) that only fixes HTML, not XML nor XUL and
b) it only fixes the problem for JS callers, not C++ callers (nor any other
languages possibly supported in the future).

I suggest that we use busters suggested fix for fixing HTML but in stead of
doing the exception mapping in JS specific code we do it in
nsHTMLDocument::CreateElement(...).

The XML case is a lot more complicated if done right, character encoding is what
makes this really hard to get correct. IMO we have two options:

1. We ignore the document encoding and write a simple name validator per the
   XML spec.

2. Consult with James Clark about using expat for validating names according to
   the encoding currently spcified in the document.

and hooking this up to nsXMLDocument::CreateElement() and friends (and
nsXULDocument too).

Comments, should I start fixing parts of this?

Comment 4

[vidur (gone)]

The HTML fix should definitely be in nsHTMLDocument::CreateElement - the 
nsJSDocument code is generated. There are similar problems in XML related to 
attributes (pretty much any method that throws an INVALID_CHARACTER_ERR). I 
believe the right thing to do is to consult James Clark about using expat to do 
some of this validation - it is the job of a parser.

Comment 5

[Johnny Stenback (:jst)]

This bug has been marked "future" because the original netscape engineer
working on this is over-burdened. If you feel this is an error, that you or
another known resource will be working on this bug,or if it blocks your work
in some way -- please attach your concern to the bug for reconsideration.

Comment 6

[Jan Carpenter]

Mass update of qa contact

Comment 7

[Prashant Desale]

QA contact Update

Comment 8

[Prashant Desale]

Updating QA contact to Shivakiran Tummala.

Comment 9

[Fabian Guisset]

jst said to reassign vidur's last DOM bugs to him, so here goes.
Marking P4 and leaving future target milestone.

Comment 10

[Johnny Stenback (:jst)]

Mass-reassigning bugs to [e-mail]

Comment 11

[Peter Van der Beken [:peterv]]

*** This bug has been marked as a duplicate of 16603 ***