Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Mozilla The Internet

Using Mozilla in Testing and Debugging 231

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."
This discussion has been archived. No new comments can be posted.

Using Mozilla in Testing and Debugging

Comments Filter:
  • by friedegg ( 96310 ) <bryanNO@SPAMwrestlingdb.com> on Tuesday April 08, 2003 @01:48PM (#5687315) Homepage
    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 [mozdev.org] add-on mentioned in the article. I used to have to visit a website and use that to view headers.
  • Venkman is good (Score:5, Informative)

    by digitalgimpus ( 468277 ) on Tuesday April 08, 2003 @01:48PM (#5687317) Homepage
    This is also a good page to checkout for more info:

    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/200 2/venkma n/01/
  • 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..."
  • ok, so.... (Score:2, Interesting)

    by Anonymous Coward
    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.
  • paradime change (Score:4, Insightful)

    by Anonymous Coward on Tuesday April 08, 2003 @01:49PM (#5687325)
    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 have noticed this too. Another big factor I believe is changes in the shareware industry where a lot of developers are deciding instead of mailing CDs out or providing downloads, they could just offer the same thing on the web. Being web based give the author more control and more flexibility over the software then if it was a "standard" application.
      • The big problem with web-based tools is that there is greater incentive for the software to become a subscription service, rather than a product. The upside to this is for every web service out there, there is an open source version trying to do the same thing, or a compiled shareware version because somebody is too cheap to sign up for the subscription.
      • the ability to claim that the reason it was not working was the WEB and not their crappy code or poorly designed sites. My company has been migrating heavily to the intranet/internet, and then looking stupid when a 3rd party router somewhere cuts off all our customers. Someday we are going to find all the left brains that were removed from our managers heads...
    • Re:paradime change (Score:4, Insightful)

      by bheerssen ( 534014 ) <bheerssen@gmail.com> on Tuesday April 08, 2003 @02:58PM (#5687711)
      Complex websites are as legitimate pieces of software as your word processor. They have routines and they maintain state (albeit painfully). They also have bugs. They can have development cycles and release schedules. Just like software. You have to pay attention to threading and memory usage just like real software.

      In short, websites are often not collections of html documents comparable to a PDF file, but true pieces of software that require thought and analysis throughout the development cycle. To get an idea of this, download a copy of phpMyAdmin [sourceforge.net] or webmin [webmin.com] and have a look at the source. Slashcode is also a good example.
  • by mwhahaha ( 172475 ) <mwhahaha AT vt DOT edu> on Tuesday April 08, 2003 @01:51PM (#5687348)
    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 just have on my front page, best viewed with Mozilla/Netscape 7 ... with a nice big link to both. Seriously, IE might load faster, but everyone i've converted over from IE, they don't ever close it once it's open... even my parents, but they use Phoenix now not mozilla (though both are installed)... so, really, for me.. i limit who views my site correctly, but seriously, once aol flips over to use the gecko rendering engine in their client... IE might as well go on to the little browser heaven... or hell.
      • True, but I'm developing for a company who does e-commerce store hosting. And the site has to be compatible for just about everyone. We always get complaints about IE 5.0 and Mac's IE because of their FUBAR javascript implementations. I am the only one in the entire company who uses mozilla. So they are always coming up with javascript stuff I never see because my browser actually works :]
        • by Christianfreak ( 100697 ) on Tuesday April 08, 2003 @02:43PM (#5687622) Homepage Journal
          That's the problem right there: Javascript. The company I work for (small business so this is easier) before I came Javascript was "IT" and slowly I've shown how you can do cool stuff with stylesheets, and how clean pages without alot of stupid javascript effects go a long way to creating happy customers.

          Convince them they don't need the JS, much less rely on it for pages to display or navigate properly and life will be much better.
    • by tijnbraun ( 226978 ) on Tuesday April 08, 2003 @02:24PM (#5687516)
      I still use HTMLtidy [w3.org] to check my pages... I would love to have something like a "stringent" mode while developing web pages (ala browser producer error instead of trying to render the html). A while ago I found out that mozilla can even be more forgiving than IE. There was some weird bug in a parser I was testing, which sometimes resulted in </tr> to be rewritten as </tr or something. Mozilla didn't care. IE was totally confused. (First time I ever found something in html that confused explorer, but rendered ok in moz). Anyways... is such a mode/plugin available?
    • by 4of12 ( 97621 ) on Tuesday April 08, 2003 @03:58PM (#5688142) Homepage Journal

      ...IE has bastardized HTML.

      That would be "Mr. Bastardized HTML" to you, thank you very much.

      IE now sets the standard for bastardization and no weasel browser doing new bastardization of HTML should get the uppity idea that it can do the same.

  • by dtolton ( 162216 ) on Tuesday April 08, 2003 @01:52PM (#5687349) Homepage
    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.
  • by Anonymous Coward on Tuesday April 08, 2003 @01:52PM (#5687350)
    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!
  • by trmj ( 579410 ) on Tuesday April 08, 2003 @01:52PM (#5687353) Journal
    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 <b>, etc tags were ruining HTML).

    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 .NET
    • Care to elaborate what you mean by "what MS did to scripting/programming languages when they released .NET"?
      • MS made their own standards when they released the .Net system. I am hoping that Mozilla doesn't decide that what they like and don't like about a certain scripting language or even HTML itself becomes their "standard" and is allowed.

        And while my comment above may have cast me in a completely anti-MS light, I do commend them for getting their act together in the CSS area long before Netscape was able to.
  • Big Advantage (Score:4, Interesting)

    by Dave W ( 1310 ) on Tuesday April 08, 2003 @01:57PM (#5687367) Homepage
    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
  • by X_Caffeine ( 451624 ) on Tuesday April 08, 2003 @01:59PM (#5687381)
    Many javascript programmers consider Mozilla to have a buggier javascript implementation than MSIE; what they don't get is that MSIE is very good at interpreting buggy code, which leads to... well, bugs and incompatibility. Mozilla forces you to do it the right way, which leads to greater compatibility in the grand scheme of things.


    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.

  • by Alderete ( 12656 ) <slashdot.alderete@com> on Tuesday April 08, 2003 @02:00PM (#5687388) Homepage
    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 [www.icab.de], 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.
    • Excellent idea! If i had mod points i'd up you.

      This makes complete sense to me based on personal experience. I work for a web shop and some users complain who see javascript errors in the status bar at the bottom of IE. It usually isn't affecting them, but users don't like to see errors!

      If the major browser makers would include this feature (even when they still have code to work around non-standard stuff) html compliance would soar.

      Even aside from that, having compliance validation right in the br
    • by bunratty ( 545641 ) on Tuesday April 08, 2003 @02:21PM (#5687502)
      I know this isn't exactly what you're asking for, but Checky [mozdev.org] is a Mozilla Plug-in that will validate the current page when you press F10. It won't help evangelism, but at least it makes it easier for web developers to generate valid HTML.
    • by robbo ( 4388 ) <slashdot@@@simra...net> on Tuesday April 08, 2003 @02:29PM (#5687532)
      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.
      • 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.

        The test_styles bookmarklet [squarefree.com] might fit the bill - it pops up a little window where you can type in CSS rules and have the page you triggered it from dynamically update based on the rules you enter. I put this bookmarklet into my Personal Toolbar Folder in mozilla, so it's just a click away.

        There's HEAPS of useful bookmarklets linked off that page too. The javasc

      • You might want to check out the Show Divs [web-graphics.com] bookmarklet.
    • I've used iCab in this way, to test sites under development. The face that shows you errors with a click is simple and effective. Heck, DreamWeaver doesn't show you errors so easily, maybe because its own scripting "behaviors" would cause so many.

      A comparable plug-in would be cool, and would underscore Mozilla's standards-compliant MO. (That's its M.O.zilla, citizen.)

      The iCab face is dang particular, though, and it seems like your page's rating has to do with the number of standards violations. You don'

    • This was discussed, and even worked on for a while, but was eventually rejected. I go agree that it would be nice to have, however.

      http://bugzilla.mozilla.org/show_bug.cgi?id=4710 8
    • Anybody know how to go about requesting this feature? Or, better yet, know how difficult this would be to implement? This kind of changes seems rather fundamental, and I would imagine difficult to do. However, Moz seems pretty well architected, so I wouldn't be surprised if this turned out not to be the case.

      Man. If I could just see an icon that indicated valid/invalid documents, life would be so much easier.

    • 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.
    • 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 [www.icab.de], 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.

      There is a simple solution, and it is to use JS favelets that connect to the W3 server with the URL details. Basically, you need a link to a JS link, such as this: javascript:window.o

  • a few criticisms (Score:3, Interesting)

    by mlheur ( 212082 ) on Tuesday April 08, 2003 @02:02PM (#5687397)
    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.
  • by American AC in Paris ( 230456 ) on Tuesday April 08, 2003 @02:02PM (#5687398) Homepage
    from the 404-file-not-*rrrrgk* dept.

    American AC in Paris [snowplow.org] 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."

  • He obviously isn't using Mozilla for load testing...

    15 comments and already slashdotted.
  • by llamalicious ( 448215 ) on Tuesday April 08, 2003 @02:05PM (#5687408) Journal
    Henrik Gemal [gemal.dk] 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 was about to express my pity for the poor guy whose overloaded server is hosting the article, when I realized that he's the one who slashdotted it!
  • by jesser ( 77961 ) on Tuesday April 08, 2003 @02:07PM (#5687419) Homepage Journal
    Web development bookmarklets: [squarefree.com]
    • 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 [squarefree.com] and keywords bookmarklets for scripters [squarefree.com] useful.
    • Another cool set of tools are the Mozilla Sidebars [netscape.com] available over at Netscape's DevEdge [netscape.com].

      Basically they add quick references into the sidebar for a variety of official standards as CSS2, CSS2.1, HTML 4.01, DOM 2, XSLT 1.0 Reference, and the Gecko DOM Reference.

      Now I've installed them I use them all the time; and to think for ages I thought Mozilla's Sidebar was useless! Very handy, it is.

  • Variable timeout? (Score:4, Interesting)

    by alispguru ( 72689 ) <bob.bane@me.PLANCKcom minus physicist> on Tuesday April 08, 2003 @02:11PM (#5687446) Journal
    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.
    • try taping down F5 ;)
    • Re:Variable timeout? (Score:5, Informative)

      by bunratty ( 545641 ) on Tuesday April 08, 2003 @02:32PM (#5687551)
      Try going to the URL about:config and changing the preference network.http.request.timeout to a large value.
    • 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.

      wget might do what you need. The -T option lets you play with the timeout if 15 minutes isn't enough.

    • So, anybody know how to make any decent browser never time out?

      1. Download the Mozilla source
      2. Find the code that closes the connection when a timeout interval has been reached
      3. Comment it out
      4. Recompile it
      5. Run

      (You'll notice I've left
      6. ???
      7. Profit!
      off the list, since those are already part of the standard Netscape/Mozilla business plan)
    • You can configure the timeout on IE by editing the registry - Google for ReceiveTimeout. It's almost certainly also possible by setting a Mozilla pref; or, if not that, then a recompile. Lastly, you could get your server to use HTTP 1.1 persistent connections, by not sending Connection: Close on a connection opened by the webserver. They'll stay up for hours.

      Gerv
  • by caino59 ( 313096 ) on Tuesday April 08, 2003 @02:11PM (#5687450) Homepage
    have it in their cache?
    ill gladly put up a mirror...someone send me the files ;o)
  • full text (Score:5, Informative)

    by Anonymous Coward on Tuesday April 08, 2003 @02:21PM (#5687499)
    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
  • by starvingartist12 ( 464372 ) on Tuesday April 08, 2003 @02:23PM (#5687515) Homepage
    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 [microsoft.com] tool available as part of a powertoy (er, Web Development Accessories) for web developers.
  • by Anonymous Coward
    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
    • Interesting? Everytime a Mozilla article pops up so does this comment. Redundant is more like it.

      But I guess however I'm in a troll feeding mood. So lets examine a few facts:

      A) Mozilla is 4 apps in one. Some people like this, some people don't. If you don't like it then use Phoenix or one of the other stand-alone browsers

      B) For an app that is four apps in one, Mozilla has a relatively small foot-print. I've got several tabs open and the mail client right now and its only using 48 megs (mostly just idle i
  • Nothing beats.... (Score:3, Insightful)

    by Richard_at_work ( 517087 ) on Tuesday April 08, 2003 @02:35PM (#5687565)
    print or echo. or print_r, or vardump. or...

    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.

  • by robbo ( 4388 ) <slashdot@@@simra...net> on Tuesday April 08, 2003 @02:37PM (#5687586)
    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..
    • If you just clone IE, what's the point of having Mozilla?

      The whole point to mozilla is to compete with IE. They are producing a superior, standards complaint browser that will eventually force microsoft to clean up their act.
      • Fair enough, but the reality for most web designers is that IE represents ~96% of their audience. From a debugging point of view, I *need* to open a page in IE, just to check that it lays out properly. Wouldn't it be nice if Mozilla obviated that need? I don't think it should be a default setting, but something the user can switch on when needed.
    • But given the fact that there are some significant differences between IE versions, which one would you emulate? All of them? Jeez.. talk about bloat, all for the purpose of emulating quirks!

      And we won't even get into IE differences between platforms either...

      Personally, one of the singularly biggest and best features of Mozilla is that it plays well with others. You can have multiple versions of it installed at a time on one box. Any webdev worth their salt will have a copy of every major browser tha
  • by wfmcwalter ( 124904 ) on Tuesday April 08, 2003 @02:44PM (#5687630) Homepage
    Opera has some one feature that (as far as I can tell) mozilla doesn't. It has a really easy way to change the rendering enging to run in a number of different modes, including small screen, text, accessibility, high contrast, and the rather fun CBM=64 lookielikie mode. Mozilla can do some of this, but Opera's handy menu access (view->style->usermode->xxx) makes testing the many pages of ones website for accessibility quite easy.

    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:

    • Opera is the standards fascist
    • Mozilla is the make-it-work-somehow guy
    • and uniformly, IE is the "problem child"
  • import com.suit.flameproof;

    if you do serious web dev., then DW is far from expensive. and it will generate correct html, even if you use lots of fireworks dhtml, or layers. it will do all your checking, and it can check for browser differences. no, it's not open source, but at least DW is very platform nuetral. it does CF, asp, php, etc. yes you need windows or a mac, and that is a drawback.
  • Live HTTP Headers?? (Score:3, Informative)

    by chickenbird ( 54590 ) on Tuesday April 08, 2003 @03:05PM (#5687757)
    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.
  • by OYAHHH ( 322809 ) on Tuesday April 08, 2003 @03:14PM (#5687806)
    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...

    • just try to write certain automated test programs with that sort of thing going on.

      Are you doing automated testing of web apps? What tools are you using? I've been looking for something that does that...

      Thanks,

      Gerv
    • That change wasn't "gratuitous". It was made to reduce the chance of accidentally clicking "close other tabs" while trying to click "close tab" (in bug 191826), without removing the "close other tabs" command completely (which was the initial fix, I think in bug 103354). If jag decides the change didn't help enough, he'll try something else.

      This type of change temporarily sucks for people who download every version of Mozilla, but it's better in the long run and it's better for people who only use major
  • by Alan ( 347 ) <.gro.seifu. .ta. .xeretcra.> on Tuesday April 08, 2003 @04:12PM (#5688208) Homepage
    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
    • 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.


      I had that exact problem until I installed the WDG HTML Validator [htmlhelp.com] on my development server (if you're using Debian, just do "apt-get install wdg-html-reference").

      When I have something in development, I add a bit to my global footer saying something along the lines of:

      if (mode == "d

"The vast majority of successful major crimes against property are perpetrated by individuals abusing positions of trust." -- Lawrence Dalzell

Working...