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)
It lets me glace at things pretty quickly to get an idea of what may be wrong, and saves me the step of loading it into a full blown editor. Plus, I can select only part of a document and just view that particular source.
I also like the http header viewer add-on mentioned in the article. I used to have to visit a website and use that to view headers.
Google doesn't index user sigs, so stop trying to "Google Bomb" with them.
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
When I read that headline I thought "what's so hard about using Mozilla in testing? Just apt-get install mozilla, same as in woody and sid..."
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
in this new roadmap the mozilla tema put out, where does this stuff fit in? Features like this are decidedly pimpin and mozilla has tons of cool features that I'm always uncovering. But the new roadmap said to focus on phoenix and minotaur. Phoenix is lean and mean and minotaur is email, where does this stuff go? I don't want to lose stuff like this.
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 :[
I have been using Mozilla because I love the tabbed browser windows. I was completely unaware of all the extra features it offers.
The DOM Inspector will be really nice for checking out the rendered structure of a page. I've always had a tough time with this since I generate most of my pages dynamically. In fact most of those tools will be *incredibly* useful in that context.
I have to say I'm really impressed with the progress the Mozilla team is making. For a while there IE was leading the way, now that trend has clearly reversed.
Doug Tolton
"The destruction of a value which is, will not bring value to that which isn't." -John Galt
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!
I have really been impressed with mozilla since they went fully standards compliant (back in '96 I remember it being all the rage to complain about netscape and how their "netscape-isms" like the , etc tags were ruining HTML).
.NET
Let's hope that with these new developer features they continue with this compliancy, and don't go and do what MS did to scripting/programming languages when they released
Work sucked, until it became unemployment, when it became slightly more tolerable. -Tet
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.
My biggest criticism is regarding the source viewer. Yes in IE the default source viewer is Notepad, but that can be changed - there's no mention of that ability in the article.
The other problem with the source viewer is that Mozilla goes to the server to grab the source, not using the exact source displayed on the screen if you're using dynamic server side variables (PHP), whereas IE gives you the source of whatever's in memory and displayed on the screen.
Other than that I prefer Mozilla too.
American AC in Paris writes "In this thread, we will describe some very cool features in Mozilla which will enable you to quickly find the maximum load of your web site and applications."
Obliteracy: Words with explosions
He obviously isn't using Mozilla for load testing...
15 comments and already slashdotted.
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 I could really use is a browser that let you set the timeout (when waiting for an HTTP transaction to come back) to something large, or better yet to turn it off completely.
I write web applications in Common Lisp, so when developing I have the Lisp top-level open and running. Errors on the server side pop up a Lisp debugger on the thread doing the transaction, I can poke around in the stack, figure out the problem, even fix it and continue - but only if I do it quickly, before the browser decides it's waited on me long enough and closes the connection, which causes a broken-pipe error on the server side and can clobber my debugger session.
So, anybody know how to make any decent browser never time out? Mac OS X browser preferred, but I'll take Linux or Windows in a pinch.
To a Lisp hacker, XML is S-expressions in drag.
have it in their cache? ;o)
ill gladly put up a mirror...someone send me the files
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
If youre going to test websites, use a proper ide. Such as dreamweaver or quanta, even vim/emacs are more suitble for the job. Then you call your external browser (or embed its rendering engine in the ide) to test it.
Mozilla dosen't even support editing in "view source". Other browsers let you call your own external editor, but not mozilla!
The truth hurts
I for one, have never found myself doing any debugging in the browser past printing to it from php. Thats how i debug, simple. My html is rarely at fault, and if it looks good in IE or Phoenix, then it rocks. I dont do javascript. I dont do stuff client side. Theres nothing for the client to debug, job done.
As an aside, this article struck me as less of a "handy things in mozilla" and more of a "oooh look at what mozilla does over IE". It really struck me as that, another flag waving rather than truely informative.
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
I'd really like a "tandem" mode, where the browser would automatically open each page in both normal and accessibility, or normal and text-only, modes (in two parallel windows, naturally).
In testing my own website for IE6, Mozilla-1.3, and Opera 7, I seem always to find the same thing:
## W.Finlay McWalter ## http://www.mcwalter.org ##
Wow, it said you could go to Tools -> Web Development -> Live HTTP Headers to see the HTTP Headers, but there is no such item in my Mozilla 1.3 Tools menu.
Hmmm, looks like they haven't implemented it for Macintosh versions.
The other nice thing to have would be an item in the DOM inspector that would show you the XPath for the selected node.
I'm,
A big fan of Mozilla, but I do have to admit that I would prefer it if things remained a tad bit more stable.
For example, from the 1.2 to 1.3 release of Mozilla the "New Tab" popup menu item moved from the 0 (zero) position in the popup menu to the 2 position.
From a day to day useability standpoint it's annoying for the menu's and the like to change around but just try to write certain automated test programs with that sort of thing going on.
I know that Mozilla is usually advertised as "test platform" but that doesn't mean that it also should serve as a point of frustration for those who would like to be able to count on a feature existing from one dot release to another.
Other than those sorts of things I love the darn thing.
Over...
Caution: Contents under pressure
It's an add-on, and the link to get it was posted earlier.
how is babby formed?
Opera provides a shortcut (Ctrl+Alt+V) that uploads the source of the active frame to the W3C validation page automagically and displays the validation results.
Mozilla has a "quirks" mode that is trying to be as forgiving as possible.
But as soon as you properly define the DOCTYPE, Mozilla only renders correct HTML.
The article notes that the cookie allow/deny dialoge is almost identical between the two browsers, but misses one huge plus for mozilla. The IE cookie confirm dialoge doesn't save it's state. I personally browse with the cookie set to "ask me" each time, and I look at the cookie that is being set, make sure my IP address or other personal-looking information is in there, and allow or deny.
In mozilla the "more" dialoge starts up open if it was open last time, but the IE dialoge always starts closed, so I have to hit "more info" each and every time. Because of this mozilla is a big winner there for me, just from this one small detail.
The nay sayers will say "no one does that", but I say that for the minority of us out there, it *does* help, and the majority will never see or be affected anyway...
1) If mozilla could do for HTML what it does for javascript.
Have a live console which shows the HTML errors
this would be very useful for web development.
I do know about the online validators but
normal development take place behind a firewall
using dynamic server-side scripting,
so every time your change the state of a page you
would have to save it and upload it to the validator.
a very slow process.
2) In the cookie tool i need a function
which remove the cookies from the current site.
So you don't have to look trough a long list of cookies
every time you test your cookie code.
3) In view source i need a function which could auto format
the HTML code.
Many auto generate pages have there HTML in one long line.
If Mozilla could auto format the code it would be useful.
4) Finally I would like the spell checker to automatically
to mark every misspelled word on the current web page.