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?
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
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?"?
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] 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.
Noted. I fixed a test failure caught by the try run in the final patch: https://hg.mozilla.org/integration/mozilla-inbound/rev/9ddc62d965dc
Documented: https://developer.mozilla.org/en-US/docs/Firefox_19_for_developers#DOM https://developer.mozilla.org/en-US/docs/DOM/document.createElement#Notes