Slashdot Mirror
Using Mozilla in Testing and Debugging
Henrik Gemal writes "In this article I will describe some very cool features in Mozilla which will enable you to quickly find and debug errors in your web site and web applications."
← Back to Stories (view on slashdot.org)
This is also a good page to checkout for more info:
0 2/venkma n/01/
http://mozilla.org/projects/venkman/
Venkman is the JS debugger in Mozilla... and it's sweet.
There is also a Netscape made intro that may be helpful to new users:
http://devedge.netscape.com/viewsource/20
websites & webpages have reached a complexity whereby mistakes are refered to as 'bugs' like as if it were software. It seems the slow drift towards the internet being the computer is slowly happening. Nowonder Microsoft was so afraid of Netscape, though they thought it'd happen much quicker, though it probably would've with the speed Netscape came up with new things (where as MS not having done any real improvements to their browser for a long time).
I normally use mozilla when I'm doing web development, however I still have to run throught he site in IE. Mozilla has great development features, but I have found that IE has bastardized HTML. Mozilla also has it's issues with tables (I'm currently having issues with non wraping text rows) and Horizontal rules (for some reason it just won't display on certain pages). You should see the code to get around the nonwraping text, my god it's horrid. Another thing is that Mozilla's javascript is slightly different than Microsoft's. I have found that IE 5.0's implementation is different than 5.5 and 6.0. Mozilla will also let you get away with certain variable addressings that IE will choke on. Mozilla is great, but you still have to use IE at some point. IE still forces us to do stupid things :[
1) write a snazzy article about website bugs
2) upload article to own website
3) submit link to own article on Slashdot
4) discover the bug the hard way when own website is slashdotted to smitherines within 20 seconds
5) ????
6) Famous!
This is a really significant advantage to Mozilla.
With Mozilla being so attractive to web developers it makes it so much more likely that sites will fully support mozilla and those developers will bring in more users.
Getting developers to use your application is a great way to build market share.
Our own developers tend to use Mozilla as the key browser already, with tests to check behaviour on IE later.
All we need now is full etester type functionality using Mozilla instead of IE (preferably Linux based). We have used many add-ons for JUnit (like Canoo Webtest), but the javascript and DOM support is always the problem. Embedding mozilla might be a better way to go.
Dave
I wish this article had addressed the whole MSIE "document.body" mess, though. The correct DOM equivalent is "document.documentelement", but it doesn't work in MSIE6 unless the document is properly defined with a DOCTYPE declaration (otherwise MSIE is in backward-compatibility/buggy mode).
Otherwise, a really great introduction. I've been using Mozilla to do javascript for months and didn't know most of the data here.
// I will show you fear in a handful of jellybeans.
I'd really like to see a simple plug-in that adds only one visible element to the standard interface, a smiley/frownie face, ala iCab, that indicates whether the HTML of the page actually validates to the DTD declared in the document itself. Clicking on a frownie face would bring up a list of validation errors. This would be a great tool for site developers, making mistakes quickly visible.
It would be an even better tool for standards evangelism if it was included in the default installation of Mozilla/Phoenix. Then you'd turn the entire population of Mozilla users into nitpickers, who would hound site developers about lack of standards compliance.
From personal experience, nothing makes you fix problems faster than users regularly sending you e-mail about things that are broken. So making it obvious when things are broken would lead to more feedback, and more feedback would lead to more standards-compliant websites.
Which would be good for Mozilla, and all other browser developers who work towards standards-compliance.
Henrik Gemal writes "With this article I will subject myself to a massive DDoS produced by legions of slashreaders who will certainly turn my webserver to molten slag."
I agree that HTML highlighting is great, but I've been meaning to post a feature request on bugzilla for some time: let me view-source in a tab, rather than open a new window. That should be really easy to do. I'd also love to have keyboard navigation between tabs (ok, it's probably there already, or at least in Phoenix, but I haven't found them yet..)
So long, and thanks for all the Phish
- shell (type JS statements to evaluate them)
- onerror status
- onerror alert
- test styles (type CSS rules; it applies them immediately)
- zap style sheets
- view style sheets
- view scripts
- view variables
- generated source
- partial source (not as good as "view selection source" in Mozilla's context menu)
- show blocks
- ancestors (makes status bar show what you're hovering over, in the format "BODY > DIV#content > DIV.blog > DIV.blogbody > P")
- make link (create HTML to link to a page)
- show named anchors
You can do many of these things with the DOM Inspector or JS Debugger, but boomkarklets usually require fewer clicks and are easier to learn. All of these bookmarklets work in Mozilla, and many of them also work in IE or Opera or both. Web developers might also find these validation bookmarklets and keywords bookmarklets for scripters useful.The shareholder is always right.
What a fool believes, he sees, no wise man has the power to reason away.
Using Mozilla in testing and debugging web sites
Mozilla is a great tool to use in developing web sites and web applications. Not as a development tool itself, like an editor, but as a testing and debugging tool. In this article I will describe some very cool features in Mozilla which will enable you to quickly find and debug errors in your web site and web applications.
JavaScript Console
A lot of the errors found in todays web pages and web applications are caused by JavaScript errors. Most of the time they're very simple errors. This is in my opinion the most common reason why sites doesn't work in Mozilla. But these errors could easily be avoided. With Internet Explorer you are, if you have set the correct setting, presented with an almost useless dialog that "page contains errors". The dialog doesn't let you copy the error to the clipboard for starters. If you want better debugging in Internet Explorer you can install the Microsoft Script Debugger which is a debugging environment for scripting in Internet Explorer.
Picture 1: JavaScript error in Internet Explorer
With Mozilla on the other hand you have the JavaScript Console. All JavaScript errors are logged here. So if you keep the JavaScript Console open while testing your site you can on-the-fly see if there are any JavaScript errors. An indispensable tool for developing web sites and web applications.
The JavaScript Console reports the error and the filename and the line number. Furthermore the context of the error is shown. This makes it very easy to get a clue about where the error is and what caused it.
Picture 2: The Mozilla JavaScript Console with errors
You can right-click on each error and copy it to the clipboard. The JavaScript Console could still need a lot of improvements. You can't save all entires to a file and it has problems with wrapping.
The JavaScript Console can be started via Tools -> Web Development -> JavaScript Console.
JavaScript strict warnings
JavaScript strict warnings are messages that are produced inside the JavaScript Engine, which is in the core of the browser. JavaScript strict warnings are produced in all browsers. In both Mozilla and Internet Explorer and Opera. But only Mozilla shows them. JavaScript strict warnings are warnings from the JavaScript Engine about some mistakes in the client side JavaScript code. These mistakes, unlike JavaScript errors, do not stop the execution of the web page. But they do slow it down a bit, since they produce an exception inside the JavaScript Engine.
Picture 3: JavaScript strict warnings
In other browsers than Mozilla these exception are not available to the developer but with Mozilla you can access these warnings. This puts you in the driver seat for making 100% valid JavaScript code!
A common mistake in JavaScript is to declare a variable twice:
var response = true;
var response = false;
This will produce a JavaScript strict warning saying
"redeclaration of var response"
The correct way is of course:
var response = true;
response = false;
The JavaScript Console can be enabled in nightly builds via Edit -> Preferences -> Debug ->. If you run a official release you can use the javascript.options.strict pref which can be set by entering about:config in the Location and hitting enter.
More info...
Tackling JavaScript strict warnings
Cookie Control
Most web sites and web applications nowadays are using cookies. Debugging cookies can be a problem. But not if you use Mozilla. If you're using Internet Explorer the only option you have from within Internet Explorer is to delete all current cookies. If you want to delete all cookies from a specific domain you have to manually delete the Internet Explorer cookie files which are located in the %USERPROFILE%\Cookies directory. Since the files are in a unknown text format I'm not sure it you can delete or edit specific cookies from a site or domain.
Picture 4: Cookie Manager in Internet Explorer
With Mozilla it's all
One of the reasons I switched from Netscape Navigator 3 to IE 3 was that when I viewed the source of a website on my local hard drive (ie: testing and debugging), IE would open the actual file in Notepad (or any other editor), while Navigator would open either a non-editable page source window or a cached version of it in Notepad (no, I'm not going to use Composer).
The same is kinda true with IE6 and Moz today. IE6 lets me move around my local prototype website and click on a large Edit button. This simplifies editing static html pages for me.
But hey, I still think Mozilla is great and invaluable for testing and debugging code. The Javascript Console mentioned in the article has saved me tons of time. I totally recommend it as the first thing to use to check for scripting errors.
One final though... IIRC, IE5.0 has had a View Partial Source tool available as part of a powertoy (er, Web Development Accessories) for web developers.
CSS validation would be cool (of course there's always w3.org)
I'd love to see something that helped me with CSS layout- a way to put big bright borders around divs and highlight their containing blocks, etc. I *don't* want that in composer, mind you, because I prefer to play with the raw source in an editor and reload the page to see how it looks.
So long, and thanks for all the Phish
Try going to the URL about:config and changing the preference network.http.request.timeout to a large value.
What a fool believes, he sees, no wise man has the power to reason away.
Don't laugh, I'm serious. It would be nice to see that how page I'm working on renders in IE without switching OS and browsers. Most of the layout bugs and standards-defiance in IE are well documented and it shouldn't be too hard for Moz to behave like IE if the user so desired.
I know, I know, I should post these requests on bugzilla..
So long, and thanks for all the Phish