This bug is for tracking if and how the XP Trees 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.

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.

Putting on [nsbeta2+] radar for beta2 fix.

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.

I was running with the pref enabled, and I came across this message in Bookmarks Manager each time I click on a twisty to expand/collapse a treeitem: Possible DOM Error: .name, .nodeName or .tagName requested on a namespace element/attribute with the qulaified name 'xul:image', is this OK? I also see this in any tree that uses twisties in the app. e.g. bookmarks, prefs, customize sidebar dialog. The one exception is in managing buddy lists in AIM, but they use 'double click to open the twisty' semantics, so they're using a different code pattern. I can't say whether this is a problem in the tree code, or if these dialogs just repeat the same error in their javascript code (or use a common library) but I thought I should note the problem.

taking these so hyatt can play Vampire

fixed. now about those pesky vampires....

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