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.


#50 Good Idea, Bad Idea?

by Anon

Monday November 15th, 1999 3:41 PM

You are replying to this message

As far as I can tell, the problem here is not that proprietary pages will break in Moz. After all, it is actually the BROWSERS which are broken.. every proprietary tag on every proprietary page is nothing more than a bug workaround. The problem is that users, being stupid (spare me the PC rhetoric, it's true and you all know it), will immediately blame the browser for the failures of the page. And indeed, who DOESN'T cuss at the TV when the cable goes out, hmm?

This isn't a good enough reason to support all of the cruft that's out there, though, IMO. Mozilla has dispensed with all of the old proprietary code on the inside, and is far superior to anything else as a result.. let's finish the job and clean up the code on the outside as well.

I think that the "Bad HTML" warning would be an excellent idea even if it didn't double as a validator. I might even take it one step further and add an error dialog which briefly explains that the page is broken, forcing the users to recognize (if not necessarily understand) why pages seem to break and whose fault it is. (I envision the dialog as having a "Don't Show Again" and a "Tell Me More" button. The function of the first should be obvious; the second could dismiss the dialog and open a local file which briefly explains how broken pages came to be and why standards compliance is important.)

As for designers and acceptance... Having worked with both Mozilla and N4, I can confidently say that anyone who wants to keep the old code is insane, as well as a masochist. The "new" code is not terribly difficult to pick up, and few things compare to being able to get a piece of code right on the first try with little or no experience, only references. I have little doubt that anyone who gives it a try will quickly see the shameful folly of their past and adopt the standards wherever possible.. and lest any of you forget, it is the designers, not the users, who shape the growth and evolution of the web. Where we lead, they WILL follow.. they have no choice.