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.
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.
Ben, how painful is this change?
Target Milestone: --- → M16
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.
Move to M18.
Target Milestone: M16 → M18
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.
Assignee: ben → don
Hmmmm, looks like we have to do these. Well Matt ... welcome back. :-)
Assignee: don → matt
This code is all clean.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
Matt, Is there a test case I can use to verify this? Thanks, Grace
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.
set output to file not seeing any errors- build 2000072408
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.