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

VERIFIED FIXED in M18

Status

SeaMonkey
Startup & Profiles
P3
normal
VERIFIED FIXED
18 years ago
14 years ago

People

(Reporter: jst, Assigned: matt)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta2+])

(Reporter)

Description

18 years ago
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.
(Reporter)

Updated

18 years ago
Keywords: nsbeta2
(Reporter)

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:

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

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

Comment 3

18 years ago
Ben, how painful is this change?
Target Milestone: --- → M16
(Reporter)

Comment 4

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 5

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

Comment 6

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
2.
Assignee: ben → don

Comment 7

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

Comment 8

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

Comment 9

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

Thanks,
Grace
(Assignee)

Comment 10

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

18 years ago
set output to file
not seeing any errors- build 2000072408
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.