Closed Bug 16591 Opened 25 years ago Closed 21 years ago

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

Categories

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

defect

Tracking

()

VERIFIED DUPLICATE of bug 16603
Future

People

(Reporter: dbaron, Unassigned)

Details

(Keywords: dom1)

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
In an attempt to get my bug list in order again, marking all the bugs I have
currently as ASSIGNED.
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.
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?
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.
Target Milestone: M17
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.
OS: Linux → All
Hardware: PC → All
Target Milestone: M17 → Future
Mass update of qa contact
QA Contact: gerardok → janc
Keywords: dom1
Component: DOM Level 1 → DOM Core
QA contact Update
QA Contact: janc → desale
Updating QA contact to Shivakiran Tummala.
QA Contact: desale → stummala
jst said to reassign vidur's last DOM bugs to him, so here goes.
Marking P4 and leaving future target milestone.
Assignee: vidur → jst
Status: ASSIGNED → NEW
Priority: P3 → P4
Mass-reassigning bugs to dom_bugs@netscape.com
Assignee: jst → dom_bugs

*** This bug has been marked as a duplicate of 16603 ***
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
Component: DOM: Core → DOM: Core & HTML
QA Contact: stummala → general
Assignee: general → nobody
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.