DOM_L2: Does XP Apps rely on old incorrect DOM Level 1 behavior



UI Design
18 years ago
14 years ago


(Reporter: jst, Assigned: matt)


Firefox Tracking Flags

(Not tracked)


(Whiteboard: [nsbeta2+])



18 years ago
This bug is for tracking if and how any XP Apps 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:

  element.setAttribute("rdf:resource", "http://...");
  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("", "html:input");
                         "rdf:resource", "http://...");
  if (element.localName == "BODY" && // element is a HTML element in XUL
      element.namespaceURI == "") ...
  if (element.localName == "TD" && // element is a HTML element in XUL
      element.namespaceURI == "") ...

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:

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.


18 years ago
Keywords: nsbeta2

Comment 1

18 years ago
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:


is the correct way.
QA Contact: sairuh → gerardok

Comment 2

18 years ago
Putting on [nsbeta2+] radar for beta2 fix. 
Whiteboard: [nsbeta2+]

Comment 3

18 years ago
Steve, can you work with Ben and Bill (who have similar bugs) to resolve this?
Assignee: don → slamm
Priority: P3 → P2
Target Milestone: --- → M16

Comment 4

18 years ago
I already have bugs on the Sidebar and Bookmarks for this. This bug seems to be
a catch all, but maybe the individual bugs are cover everything.

Comment 5

18 years ago
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 6

18 years ago
Move to M18.
Target Milestone: M16 → M18

Comment 7

18 years ago
Ben ... sorry.
Assignee: slamm → ben

Comment 8

18 years ago
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
Assignee: ben → don

Comment 9

18 years ago
Hmmmm, looks like we have to do these.  Well Matt ... welcome back. :-)
Assignee: don → matt

Comment 10

18 years ago
This code is all clean.
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 11

18 years ago
Development issue; marking verified according to developer's comment.
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.