This bug is for tracking if and how the XP Menus 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.
Status: NEW → ASSIGNED
Target Milestone: --- → M19
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.
Moving undated nsbeta2+ non-feature bugs to M18.
Target Milestone: M19 → M18
Whiteboard: [nsbeta2+] → [nsbeta2+] 6/15
mass-moving all dated nsbeta2+ bugs to M19
Target Milestone: M18 → M19
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.
didn't have to change anything, but i ran with the pref and searched through the code. in xpmenus, all refs to tags or attributes are in namespace none. reopen if this is in error.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
verified per pinkerton (I also ran with this and found a problem with trees but not with any menus).
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.