Closed Bug 802562 Opened 7 years ago Closed 7 years ago

createElement(null) should work like createElement("null")


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

Not set





(Reporter: ayg, Assigned: ayg)


(Keywords: dev-doc-complete)


(1 file)


  Element createElement(DOMString localName);

This means localName has the default WebIDL behavior for null, which is to stringify to "null".  This seems to be what Opera does.  We throw INVALID_CHARACTER_ERR, as does Chrome, and IE throws "Unspecified error.".  It probably doesn't matter which way we go, but the platform default is to stringify to "null", so we should go with that unless we have good reason not to in this specific case.

This shouldn't conflict with any pending patches to port to Paris bindings, right?
Attached patch PatchSplinter Review
Tested by <>, which will make its way into our mochitests on the next sync.  Try:
Attachment #672272 - Flags: review?(bzbarsky)
We should maybe think about how to deal with all these null-to-"null" issues, though -- we probably don't want to add Null(Stringify) to every place where the specs have no annotation, right?  Do the new WebIDL bindings match the WebIDL spec, or do they also default "DOMString" to the equivalent of "DOMString?"?
Flags: in-testsuite+
The new bindings match the spec. Adding Null(Stringify) in places where we're not yet moving to the new bindings seems sensible to me.
Comment on attachment 672272 [details] [diff] [review]

What Ms2ger said.  If we really care, we can make changes like this, but the goal is to have all nodes on WebIDL in the next few months, so most of those should Just Work after that.... assuming the spec IDL is not buggy.

r=me on this, in any case.
Attachment #672272 - Flags: review?(bzbarsky) → review+
Noted.  I fixed a test failure caught by the try run in the final patch:
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla19
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.