MozillaZine

Reporting DOM Bugs? Be Sure to Read This!

Monday November 8th, 1999

Eric Krock has a request for anyone report DOM bugs:

"Please bookmark the below URLs!!!

If you hit a page that doesn't display well or has JavaScript errors in Nav5 (Mozilla) because the page uses MS IE4/5 DOM features, Nav4 Layer DOM features, or the LAYER/ILAYER tag, DON'T FILE A BUG in Bugzilla. Instead, use the below email creation templates to send an email to the page's owner asking them to upgrade the page to support W3C standards.

If the page supports IE4/5 but not HTML 4.0/W3C DOM:
http://sites.netscape.net/ekrock/fixit/ie.html

If the page supports Nav4 but not HTML 4.0/W3C DOM:
http://sites.netscape.net/ekrock/fixit/layer.html

If the page is breaking because of user agent detection problems:
http://sites.netscape.net/ekrock/fixit/useragent.html

(Use that one when a page doesn't work or has a JavaScript error because the client-side JavaScript isn't detecting the Navigator 5 Mozilla/5.0 userAgent string, or discover that a server-side CGI is returning the wrong page because it's not detecting the Mozilla/5.0 HTTP USER_AGENT string or is choking on its HTTP 1.1 CONTENT_TYPE string.)

Likewise, if you're examining a bug report in Bugzilla and realize it's caused by these issues, mark the bug INVALID. Then use the email creation templates to notify the bug reporter and the page owner of the need to upgrade. Bugs closed as INVALID in this way count half a point in the BugAThon!

Hint to avoid filing bogus bugs: if content on a page doesn't position correctly or there's a JavaScript error, do a View Source and look (or copy and paste and search in a text editor) for the strings document.all and layer (case insensitive). If you find those strings in the JavaScript or the HTML markup, think twice before filing a bug. Create a simplified test case without the proprietary features and see if the problems still occurs.


#34 Ugh

by Anon

Tuesday November 9th, 1999 5:55 PM

You are replying to this message

Hmmm,

Have you developed for the Netscape 4 DOM? It's not pretty and has some annoying quirks. I have no reservations saying that I much prefer IE 4's approach to DHTML over Netscape 4's. I've spent many painful hours working with Netscape 4 and I'd not wish that on anyone (there *is* some logic behind the implementation, but it can be rather inconsistent).

At the moment the best way support IE4/5 and Netscape 4 at the same time is to use a crossbrowser API (Dan Steinman's DynLayer is well known) and I've developed my own one to support the work I do (we are writing a servlet-based application that has a full DHTML interface - pull down menus and the like). As my API evolves I intend to support IE4, NN4 and DOM1 (which should work in IE5 and Moz) and to make the API available for anyone to use. The biggest limiting factor will be Navigator 4 because it supports fewer CSS properties and provides relatively limited access to all the objects on a page.

The DOM approach - explicitly adding nodes to a tree - is somewhat different to the approach used in version 4 browsers so I anticipate current crossbrowser APIs will have to evolve a little... but an anticpiate many of them will be ready by the time Mozilla is released as Navigator 5. In a few years time we should see DOM Level 1 compliant browsers having 80+% market share and the need for these crossbrowser APIs will start to disappear thanks to the wonder of standards compliance.

I support the move of the Mozilla team to break with the past and not implement support for older DHTML because the DOM1-based approach is much more theoretically sound and offers more features to the developer.

XUL should also give Mozilla an advantage for organisations planning to implement intranet applications.

-Walter