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)
Core
DOM: Core & HTML
Tracking
()
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
Comment 1•25 years ago
|
||
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?
Comment 4•25 years ago
|
||
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
Comment 5•24 years ago
|
||
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
Updated•24 years ago
|
Component: DOM Level 1 → DOM Core
Comment 9•23 years ago
|
||
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
Comment 11•21 years ago
|
||
*** 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
Updated•14 years ago
|
Assignee: general → nobody
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•