Last Comment Bug 802562 - createElement(null) should work like createElement("null")
: createElement(null) should work like createElement("null")
Status: RESOLVED FIXED
: dev-doc-complete
Product: Core
Classification: Components
Component: DOM (show other bugs)
: Trunk
: All All
: -- minor (vote)
: mozilla19
Assigned To: Aryeh Gregor (:ayg) (next working March 28-April 26)
:
: Andrew Overholt [:overholt]
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-17 05:57 PDT by Aryeh Gregor (:ayg) (next working March 28-April 26)
Modified: 2013-03-23 13:26 PDT (History)
5 users (show)
ayg: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Patch (1.45 KB, patch)
2012-10-17 06:04 PDT, Aryeh Gregor (:ayg) (next working March 28-April 26)
bzbarsky: review+
Details | Diff | Splinter Review

Description Aryeh Gregor (:ayg) (next working March 28-April 26) 2012-10-17 05:57:48 PDT
Spec:

  Element createElement(DOMString localName);
  <http://dom.spec.whatwg.org/#document>

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?
Comment 1 Aryeh Gregor (:ayg) (next working March 28-April 26) 2012-10-17 06:04:48 PDT
Created attachment 672272 [details] [diff] [review]
Patch

Tested by <http://w3c-test.org/webapps/DOMCore/tests/submissions/Ms2ger/Document-createElement.html>, which will make its way into our mochitests on the next sync.  Try: https://tbpl.mozilla.org/?tree=Try&rev=c27d9953571a
Comment 2 Aryeh Gregor (:ayg) (next working March 28-April 26) 2012-10-17 06:06:04 PDT
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?"?
Comment 3 :Ms2ger (⌚ UTC+1/+2) 2012-10-17 06:46:14 PDT
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 4 Boris Zbarsky [:bz] (still a bit busy) 2012-10-17 09:26:16 PDT
Comment on attachment 672272 [details] [diff] [review]
Patch

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.
Comment 5 Aryeh Gregor (:ayg) (next working March 28-April 26) 2012-10-28 05:27:30 PDT
Noted.  I fixed a test failure caught by the try run in the final patch:

https://hg.mozilla.org/integration/mozilla-inbound/rev/9ddc62d965dc
Comment 6 Ryan VanderMeulen [:RyanVM] 2012-10-28 14:02:32 PDT
https://hg.mozilla.org/mozilla-central/rev/9ddc62d965dc

Note You need to log in before you can comment on or make changes to this bug.