39932 - DOM_L2: Does XUL rely on old incorrect DOM Level 1 behavior

Status: VERIFIED FIXED

(Core :: XUL, defect, P3)

Description

[Johnny Stenback (:jst)]

This bug is for tracking if and how XUL in mozilla breaks
when the old incorrect way of manipulating a DOM document containing XML
namespace elements in mozilla is replaced with the new correct DOM Level 2 way
of dealing with elements in a XML namespace aware application.

The old incorrect implementation allows for code like this to work:

  document.createElement("html:input");
  document.getElementsByTagName("html:checkbox");
  element.setAttribute("rdf:resource", "http://...");
  element.getAttribute("rdf:resource");
  if (element.tagName == "BODY") ... // element is a HTML element in XUL
  if (element.nodeName == "TD") ... // element is a HTML element in XUL

The correct new DOM Level 2 way of doing the above would be something like this:

  document.createElementNS("http://www.w3.org/TR/REC-html40", "html:input");
  document.getElementsByTagNameNS("http://www.w3.org/TR/REC-html40",
                                  "html:checkbox");
  element.setAttributeNS("http://www.w3.org/1999/02/22-rdf-syntax-ns#",
                         "rdf:resource", "http://...");
  element.getAttributeNS("http://www.w3.org/1999/02/22-rdf-syntax-ns#",
                         "rdf:resource");
  if (element.localName == "BODY" && // element is a HTML element in XUL
      element.namespaceURI == "http://www.w3.org/TR/REC-html40") ...
  if (element.localName == "TD" && // element is a HTML element in XUL
      element.namespaceURI == "http://www.w3.org/TR/REC-html40") ...

One of the perhaps biggest changes, and the thing that is probably hardest to
find, is that .nodeName and .tagName on elements, and .name on attribute nodes,
contains the qualified name (ie "html:TD") in DOM Level 2 if element has a
"html" prefix in the file, or if it was dynamically created with a prefix,in the
old incorrect DOM Level 1 implementation .nodeName, .tagName and .name contained
only the "local" name, and no prefix.

For more information about using DOM Level 2 in XML namespace aware
applications, such as the mozilla XUL, see:

  http://www.w3.org/TR/DOM-Level-2/core.html

I'm hoping that I can check in code that lets people enable and disable this new 
behavior by setting a preference, this should be helpful in checking what relies
on the old behavior, the code I'd like to check in also prints out warning
messages on the console when code that assumes the old incorrect implementation
is executed, this will not catch all places, but it should offer some help.

I suspect that most of the changes are in the JS and XUL files in mozilla, but
there could of course be C++ code that relies on the old DOM code too.

The PDT team is aware of this change and a carpool will be arranged where the
DOM Level 2 updates will be turend on permanently and the changes needed to
fix this bug should be checked in, this bug will be updated once the date for
the carpool is set. Mozilla does currently have most of, if not all, the code
necessay to do the changes, but the old way still works.

Comment 1

[Johnny Stenback (:jst)]

Argh! My original comment contains two errors! The second argument to the
getXxxNS() methods should be the local name only, not the qualified name, IOW:

document.getElementsByTagNameNS("http://www.w3.org/TR/REC-html40",
"checkbox");
element.getAttributeNS("http://www.w3.org/1999/02/22-rdf-syntax-ns#",
"resource");

is the correct way.

Comment 2

[Peter Trudelle]

reassign to hyatt for triage, cc evaughan

Comment 3

[leger]

Putting on [nsbeta2+] radar for beta2 fix. 

Comment 4

[Johnny Stenback (:jst)]

The temporary code that lets you turn on the new behavior by setting a pref is
now checked in, to enable the new behavior, add this to all.js

pref("temp.DOMLevel2update.enabled", true);

With this pref enabled you'll see output like this:

Possible DOM Error: CreateElement("html:input") called, use CreateElementNS()
in stead!

if the old incorrect behavior is expected. This temporary code does it's best to
issue warnings when possible, but it's not quaranteed to find all the problems
for you.

Comment 5

[Mike Pinkerton (not reading bugmail)]

taking these so hyatt can play Vampire

Comment 6

[Mike Pinkerton (not reading bugmail)]

fixed. now about those pesky vampires....

Comment 7

[John Morrison]

per pinkerton, and from running with the pref on, verified fixed.