39922 - DOM_L2: Does the profile manager rely on old incorrect DOM Level 1 behavior

Status: VERIFIED FIXED

(SeaMonkey :: Startup & Profiles, defect, P3)

Description

[Johnny Stenback (:jst)]

This bug is for tracking if and how the profile manager 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

[leger]

Putting on [nsbeta2+] radar for beta2 fix. 

Comment 3

[don]

Ben, how painful is this change?

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

[don]

Move to M18.

Comment 6

[don]

Reassigning these to me until I figure out who should be doomed with them (other
than Ben who's already way to doomed) or somehow get them off our plate for beta
2.

Comment 7

[don]

Hmmmm, looks like we have to do these.  Well Matt ... welcome back. :-)

Comment 8

[matt]

This code is all clean.

Comment 9

[Grace Bush]

Matt,
Is there  a test case I can use to verify this?

Thanks,
Grace

Comment 10

[matt]

add this code to all.js
pref("temp.DOMLevel2update.enabled", true);

Then run the browser and see if there are any warnings that
get dumped to the console.  On a none debug build you might
have to set the output to be saved to a file.

Comment 11

[Grace Bush]

set output to file
not seeing any errors- build 2000072408