M12 Out!Tuesday December 21st, 1999M12 is now out. Get it from the FTP site. It might be a little difficult to get in. If you have a mirror site, let us know in the forum, and we'll add your info to this news item. So far there are releases for Mac, FreeBSD, Sparc Solaris 2.7, Windows, OpenVMS and Linux. Well the rest of you guys enjoy M12 and the builds following it, I probably won't get to until early January because I'm at home for the holidays with infrequent web access with my brother's labtop. <:3)~~ Okay my brother probably doesn't like me putting stuff on his laptop but he's not home so I snuck M12 onto here and let me say that it's great! Still plenty room for improvements but I think that all those involved with Mozilla should get a round of applause for getting out this wonderful build just for the holidays (okay, I don't get much of a Christmas ...) <:3)~~ I'm tryin' it now. I really like the improvements in the mail client. I think I'm going to try using this stuff as my main browser/mail program now. Just two things I'd like to see. When are fonts going to be supported and when will I be able to make a desktop shortcut for the Linux version? Jonathan Yes, I think fonts are the one major thing missing. I couldn't quite put my finger on it before but I guess it's the fonts that make the pages look "different" under Mozilla. I don't quite know what's wrong with font support though, if I use stylesheets the fonts look exactly the same with IE as with Mozilla (well, almost exactly). However, if you look at pages like: http://www.shugashack.com http://www.voodooextreme.com with Mozilla, NS and IE you will notice a HUGE difference. [Bug 991] Changed - [DOGFOOD][4.xP] font tags containing blocks are 'badly' parsed http://bugzilla.mozilla.org/show_bug.cgi?id=991 Havn't tried it out yet but i got a mail about it being fixed /Tobias To make a desktop shortcut, just create a shell script that moves to the directory mozilla's in, and runs it. (You just needed to set the CWD) For example: #!/bin/sh cd /big/stuff/mozilla/package ./mozilla That's it. You might want to launch that in an xterm etc. so you can see the debugging spew. Been trying a few of the M and nightly. It keeps gettig better and better. This is my first try here. Using M12 One small step for mozilla. One giant step for mozilla kind. So, is this the alpha or is this just one step closer to it. I couldn't find the version with the install/uninstall for windows. Also, all the debug info was still there. I've been rying mozilla since around M2 and I have to say that it is really starting to take shape now. I compiled the source to M12 while nothing else was on the ftp site and ran it under RH 6.1. So far it is pretty solid. I can notice a definite improvement in stability and speed from previous builds. I can't do anything but praise everyone who is working so hard on this project. If this is supposed to be an alpha build (10/21 M12), then I can't wait fer the beta. Runs ok under win98, but on my mac @ home, it's dog slow (i also had to copy this text and switch to comm 4.7 to submit this post!)! Keep it comin, guys! You're doing a great job! I got an email from someone at Mozilla saying that M12 isn't up to their alpha standard... so M12 is not the alpha. Perhaps someone who knows could tell us when the alpha will be coming out.... As some may remember I couldn't get M11 to launch at all on my system. M12 is going, in fact I'm using it right now. I used the installer program and let me tell you, it gave a new meaning to slow. It took 13 minutes to install on this 225 Mhz sytstem with 96MB of RAM. It's a 603e but it still shouldn't take that long. I like the chrome except for the way the buttons overlap into the grey area on the button bar. Looks tacky to me. The text fields are a little odd, wrapping doesn't seem to work quite right and the cursor seems to jump to odd places if I type to quick. I managed to pop the customize area of the sidebar open once but couldn't make any changes and it won't open again. Can't seem to change themes from the preference either. Is it just my imagination or does Mail and News use a different chrome? I like that one. Speed is decent, it's not as fast as Mac IE or Communicator 4.7. I'm undecided as to whether it's quicker than iCab or not. Considering this is, maybe, Alpha 1 I'd say I'm pretty impressed. If Mozilla's progression is anything like iCab's than performance should be blazing when it's done. Each iCab *beta* get's a little quicker and at alpha level Moz is almost as fast. iCab has the clear advantage in RAM footprint and install, it doesn't even need an installer. It doesn't do javascript, yet, or have a mail/news client though. The tab in Moz isn't working as it should, apperantly. Anyhow, I've never used Alphaware before so I'm sure all these bugs are quite normal and will be mostly solved by beta. Mozilla is turning into an impressive package, I just hope things like launching and installing get much, much faster that right now is it's biggest flaw IMO. PS: I was surprised to see the installer refer to this as Netscape Communicator 5.0. I thought they were to be entirly different packages with Netscape branding their own. This is the first Moz I'm not trashing right away, it hasn't crashed and it's pretty useable. > Install. I have to agree the install is way too long, but in the installed folder you'll find about 70 Megs and thousands of files. I hope that when we're closer to relaease, all these files will be consolidated into a few libraries and a single app... that should help the install time a lot. All the tabs, prefs, fonts, chrome issues will be addressed in due time I'm sure. >iCab. It has a small footprint because it doesn't do very much except render 3.0 pages. Add JS, Plugin support, full CSS support, etc. etc. and I'm sure it'll get bigger (but surely not 72MB of space and 18MB of Ram). >Speed. Moz is way slower on the Mac than IE or Nav. This must be addressed by the final release; especially since after applying the 'browser tips' recently mentioned on macintouch.com, both Nav and especially IE4.5 are way faster. Let's hope they address all these issues, I'm sure they will, because I can't stand using MS products unless I have to, and I really don't see iCab as a viable option for the near future. Chris There was a discussion about the number of files at another forum I frequent. The Finder count's 1,300 items at 25 MB for Mozilla while Netscape Communicator is 120 items at 21 MB ( I rounded) I do expect that to be cleaned up by beta. Opera is a fully featured browser and it's as small as iCab. I think iCab will be a viable alternative once it's supports Javascript and plug-ins. They claim it supports standards, including CSS 1.0. I'm not an expert. Speed wise I tested it against Netscape and IE (pre patch) and it fared well. It was slowest but only by a few seconds. This was iCab 1.6 and 1.8 has made speed improvements. I'm amazed at IE 4.5 after applying that proxy "patch" It completely blows away anything else on the Mac. I feels it's right up there with IE 5 for Windows. I used IE 5 on a quicker PC for a week and the patched IE 4.5 feels almost as snappy, can't wait to get my G3 upgrade. I don't like using MS products but IE is the fastest browser right now and it's the only MS product I use. Outlook is crap IMO. I think Green Mail is great. I'm confidant that Moz will continue to improve with each release. Look how far it's come from M11- M12, imagine what it'll be like in February. RickG fixed that bug yesterday (closed about 50 bugzilla entries!). It had to do with residual style entries. Download an M13 build and try it out. Special thanks go to the thoughtful person(s) who built the FreeBSD version (finally). Cheers! I've been having to write all of my web pages in windows because M8 was the last FreeBSD version. Now I can return to development on a desktop that I can actually use. Three cheers for M12-FreeBSD Big thanks goes out to: toshok@hungry.com,saska@acc.umu.se,lennox@cs.columbia.edu,mreimer@vpop.net,daeron@shadowmere.student.utwente.nl,edwin@woudt.nl. John D. Polstra and Jordan K. Hubbard of FreeBSD who got an important bug fix into the 3.4 release just in the nick of time. I am sure i left out a bunch of other people. I hope you guys don't mind me posting your emails here. But we are excited to be running on FreeBSD again. Yippeee!! pete Unfortunately M12 crashes during startup running under WinNT 4.0 SP6 (bug 21673), which makes it completely unuseable on the box at work. Also XPCOM isn't threadsafe (bug 18110), so it also dies (usually very quickly) on SMP systems, which makes it unusable on the Linux box at home. M11 would at least run, in the former case anyway. I think the NT issue (bug 21673) is solved. I was getting the same results on NT SP5. Here's the comment from Bugzilla that fixed it for me. ------- Additional Comments From jarto@starsoft.fi 1999-12-22 07:17 ------- This is probably a duplicate with bug 19165. App won't start with old MSVCRT.DLL. Solve it by downloading a mozilla build with the installer. Run setup, which also installs the newest DLLs. -------- Installing with the Win32 12-21 build /w installer did the trick. Where is this installer that you mention? I don't see it on the 'zine or mozilla.org site. I haven't had mozilla running since I downloaded a nightly build last week. Now, M12 won't even start. pretty similar situation: WinNT4 w/sp5. help! we're going backwards..... Just to note that Debian has M12 packages in the unstable distribution already. Just do "apt-get install mozilla" to get them :) Using it now and it seems very nice... the bug with transparency in the last build I tried seems to be fixed, but tabbing between form fields seems to have regressed - that's a shame. Since this is the first thing I'm doing with it, I can't comment on any other aspects... Stuart. WOW. I've been downloading the daily builds...but this is really polished. Most of the work has been going on under the hood, but using Mozilla now is (almost) like getting a new present under the tree. Things are looking very polished and professional. I've even ventured to download all my mail to try out the mail reader. Nice job. anyone else on a Mac (I'm on OS 9) able to increase the RAM in the 'get info' window. Whenever I try, it zaps the finder fast. I'm goin' back to M13 nightlies. I started using M11 a while ago, and it didn't seem to want to run that long on my iMac. I just got M12 today and it seems a bit better, but is still very slow(especially installation) and I only got to use it for about 10 minutes before I got my first crash. Still, things are looking better than they did in M11. iMacs generally have 32 megs of RAM, which is the main reason why Mozilla is currently so slow on it. It's noticeably faster if you have at least 64 megs. <:3)~~ I have 64 Megs installed on my iMac. It is still really quite slow. Any suggestions on what I may do to improve this? Vote for these bugs! http://bugzilla.mozilla.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&rep_platform=Macintosh&op_sys=Mac+System+7&op_sys=Mac+System+7.5&op_sys=Mac+System+7.6.1&op_sys=Mac+System+8.0&op_sys=Mac+System+8.5&op_sys=Mac+System+8.6&op_sys=other&email1=&emailtype1=substring&emailassigned_to1=1&email2=&emailtype2=substring&emailreporter2=1&changedin=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&short_desc=perf&short_desc_type=substring&long_desc=&long_desc_type=substring&bug_file_loc=&bug_file_loc_type=substring&status_whiteboard=&status_whiteboard_type=substring&cmdtype=doit&newqueryname=&order=%22Importance%22&form_name=query Hey people, I'm new in here, and i have to tell you, that m12 (win32-version) is excellent. Even on my 75 Pentium with 24 mb ram it is faster than ie5. I wanted to take it as general browser, but when i wanted to load the following page www.prosieben.de nothing happened. Even if i hit the reload button. Nothing, it didn't crash or so, but it didn't load the page. Somebody should know it i think, because you don't surf so much on german pages, do you? And it has problems to load chats, it doesn't load the chat-cgi frame. But you really did a great job by now. Let's beat ie5. The link is: http://www.prosieben.de Sorry for this :-) For those Mac users out there... I'm running MacOS 9. I first downloaded the version of Moz that is linked from the mozilla.org page. ftp://ftp.mozilla.org/pub/mozilla/releases/m12/MozMacInstaller-M12.sea.bin Has anyone else tried this version? On my PowerBook G3 (MacOS 9, 128Mb RAM), all the icons in the Moz folder were corrupted, the Finder became unstable, and I could not modify the amount of RAM the Mozilla application was given. The numbers kept automatically changing to impossible numbers (like negative numbers). Weird. Could it be a virus? The normal installer worked much better for me. ftp://ftp.mozilla.org/pub/mozilla/releases/m12/mozilla-mac-M12.sea.bin Hope that helps someone... This application is becomming more PC (Windows) like with every new revision. If any Mac users out there can give concrete reasons why things should be changed by pointing to sections in Apple's HIG, go to Bugzilla (there's a link from the mozilla.org homepage) and help the effort. - Adam M12 works on my site now, so I assume they fixed some problems with relative addresses. It still does not work on my colleague's start page. Does Mozilla have a problem with image maps? I was unable to post to this message board with M12, but I was able to do that with M11. Mozilla seems to lock up my computer every time my Zip drive powers down. I do not know if there is a conflict between the Iomega software and Mozilla, or if locking up the computer causes the drive to power down. I cannot use Mozilla if I have to choose between the browser and my disc drive. The only thing that could be worse is having my background destroyed for "Active Desktop Recovery". The full circle software has never worked on this computer, not even with Netscape 4.x. Any suggestions to get it working? Maybe I should attempt to get a bugzilla account. I've typed these comments to help, not to criticize. Why do I get the error message: error: mozilla-browser-5.0-M12.i386.rpm cannot be installed when I try to install mozilla on my standard RH6.1 system (the binary rpm package) It _should_ be possible to just download and "rpm -i" the package. please send me a mail if you reply to this post. #38 Re: error: mozilla-browser-5.0-M12.i386.rpm cannotby caseyperkins Wednesday December 22nd, 1999 11:18 PM Thue, I don't think what you installed was the full install, but rather the second of three rpm files. You actually need to rpm three separate packages - first, rpm mozilla-install-5.0-M12.i386.rpm, next mozilla-browser-5.0-M12.i386.rpm, finally (if you want the mail and news features) mozilla-mail.5.0-M12.i386.rpm. That is what worked for me. Casey Perkins I figured there was something wrong with the dowload - maybe files corrupted, so I just downloaded again. I installed in excatly the same way, but it worked this time. the rpm version on the download site was even the same... -------------- Now why does mozilla use 100% of my cpu-cycles just to edit this message? I would suggest that anyone who is having trouble installing the zipped version of M12 try using the installer version. I was having problems installing any M12 or later build. Immediately after clicking Finish on the create new user window I would get an error stating that Mozilla had perfomed an illegal operation and the program would shut down. However I found that the Installer based version worked fine. I actually haven't used M12 yet, I'm using a daily build of M13 but since it came out only 1 day after M12 I assume that they are probably no too far apart features/performance wise. I have to say that the peformance has improved dramatically. M11 was so slow that I could never stand to use it long enough to really try it out. It could take 10 seconds or longer just to display a menu when I clicked on the menu bar and web page display was just as slow. On the other hand M13 is very usable and I look forward to actually using it on a regular basis now. It's still no speed demon, but if you've been put off by Mozilla's performance in past milestones I would encourage you to give it another try. FYI: I am running Mozilla on a P133 64MB RAM. Considering how it performs on my machine I can understand how others would say that its performance was close to that Navigator 4.x now. On a newer computer (say...300mhz+) it would not surprize me if there was little or no noticeable slow down. Anybody else think the accelerator keys are wrong for Linux? With Navigator 4.x, the accelerator keys used the ALT key (ALT-C for copy, ALT-V for paste). I've always found that really annoying since KDE, Gnome and even Windows defines accelerator keys with the CTRL key. I'm interested to know what other people think. I'm using build 1999122208 on Linux. I've also logged a bug (ID = 22515) if anyone agrees with me and would like to vote for it. David I completely agree. I've been downloading mozilla builds for windows, but just recently acquired a linux build. I was surprised to see the Alt key used in all the keyboard shortcuts, since Ctrl is pretty much the standard in other X programs, with the unfortunate exception of Netscape 4. Please, let's change it to Ctrl, or at least let the user configure it. even odder, there were some earlier versions of mozilla where the keys _were_ all based on ctrl. It changed around M11 for some reason.I think this is a case where regularity across an OS is more important than regularity across multiple versions of the product I agree 100 percent. Mozilla is, after all, not Netscape. So it would very silly to use an incompatible, unprofessional shortcut scheme. This is a problem on Windows too, BTW. With all the versions of (linux)Mozilla i have tried some hit counters don't display right...some show up as all 8's others dont show at all. Like the one at my site: http://hackme.dhs.org Is this a problem with Mozilla or just baddly coded counters? All versions of netscape and IE show them fine. I downloaded and compiled M12 and its MUCH more stable then M11. And for the hell of it i got the nightly build(199912208 Linux) of M13 and I have just one word: WOW! This thing is FAST! Scrolling is smooth and doesnt turn the whole page gray. The arrow keys work again and so does TAB. Now if they can just fix that bug in compose that keeps you from inserting a image then I'll be happy as hell. Keep up the good work Mozilla guys! Been running M12 on my 166/64MRAM (Win95) machine since the Win32 build showed up on the server. I haven't tried the installer. There are some minor bugs, but the browser and email are both working fairly well. Arrow and PgUp/PgDown keys aren't working at all for page scrolling and are unpredictable in text boxes. There are still a few rendering bugs (MozZine is a good example -- the right column isn't showing up, and the pages are scrolling horizontally at 8X6 res). Form buttons definitely need some work. But I am really impressed by the improvements in the sidebar -- I had no trouble importing and using my NS 4.7 bookmarks (a 150k file). I'm using M12 for about 90% of my surfing and some of my email as well. (Question: M12 is still leaving POP mail on the server by default, right?) Niggling little details aside, it's basically feature-complete and usable for everyday surfing. I don't care what anybody else says about what to call this release, I say, "Congratulations on the alpha ...ON TO BETA!!" :-) Ok, I downloaded the M12 build for testing on my NT4SP6 system, and it works like a dream, except that it killed an email without a trace - downloaded and trashed in one hit! Ah well, nothing's perfect in the Alpha release :) Merry Christmas Guys! #51 Stable on NT and Wheel mouse supported on Win98!!!by Hendy99 Saturday December 25th, 1999 4:14 AM WOOHOO!!!!!!!!!!!!!!!!!!!!!! M12 is GREAT, and the nightly builds for m13 are even better.. tons of little stuff is working again! I've now totally switched over from NS4.7 to Mozilla for my brower and excpecially Mail needs.. Really looking sharp. Quick question though, does anyone know how to get Flash to work in Mozilla? I see (some how) flash 3 is installed.. but what about flash 4?? Thanks CHeers! That's pretty cool. I installed Flash 4 into Netscape 4.7 and it somehome Mozilla grabs it from there.. pretty wild! --Jed posted on m13 nightly I installed M12 for Mac. It crashed twice within the first five minutes of use: once when trying to hide the sidebar from the View menu, and once when trying to navigate within netscape.com. In ten minutes of use I also observed these bugs: 1. Closing the browser window leaves the File and other menus missing most of their items and full of divider lines, with no way to navigate or open a new windows. 2. Command-key menu shortcuts only work if you click on the menu bar first. 3. Command-click on a link doesn't open the page in a new window. 4. Page Up, Page Down, Home and End keys do nothing. 5. Scroll bars do not conform to Mac UI standards, and are very confusing because the empty fill color is darker than the thumb. 6. Pressing Next and Sign In buttons on My Netscape first time registration page has no effect. 7. Open File dialog does not put text cursor in edit field when dialog comes up -- must click to type. 8. Popup menu arrow appears on all blank text fields even though the popup contains no items. So let's see, that's about one bug per minute, and MTBF is about three minutes and twenty seconds (two crashes and one unusable state in ten minutes). It's not clear to me how anyone could think of this as an alpha candidate. The stated alpha criteria have MTBF in the one hour range. This is not even close. Echinacea Feldercarb Sorry, forgot one bug: 9. Open File and click on the Open in New Window button: nothing happens. Echinacea Feldercarb MTBF is not consistant between machines - or OSes - on NT I can leave Mozilla up for hours at a time, whilst the same build will play up violently on Windows 98. Played with M11 on an imac, but um....... too slow and no eassy way to enter proxies (speed was not really an issue here). This is more or less Alpha material. ALPHAS HAVE MANY BUGS and not all features are implimented at this stage. I would be more than happy to class M12 or the M13 Nightly builds I use as Alpha. but not all systems are the same, meaning it may not be Mozilla at fault (is probably true that it's Mozilla, but what else could cause it?) Just my $0.02 Posted with the Christmas Day Build :) Also, I see bugs. The submit button's test is not centred (It's so bad it reads SUBMI right-aligned) but I live with it. This is Alpha not beta :) Echinacea, did you double-check the bugs you found with the listings in Bugzilla? Some of those may have been already reported and are being worked on for M13. Hey, you're still with us for M12 -- I know you hate its performance and all; Hmm, I think someone has Mozilla fever. ;) No, I didn't check Bugzilla. I don't know how anyone can wade through 5,200 bugs to see if one has been filed already, especially at modem speeds. If you know of a way to do this in minutes rather than hours, I'm all ears. I have never raised a performance issue. You must have me confused with someone else. My concern is the defect density, which still seems very serious. One bug encountered per minute of use, three crashes every ten minutes -- whew. Not my idea of alpha. Echinacea Feldercarb You don't actually have to wade through 5000+ bugs (although that might be fun) Go to bugzilla's query page and you will see that there are extensive search capabilities. With a couple minutes of thought and searching it's pretty easy to find the bug you're looking for. I generally spend about 3 minutes looking for a bug and if I don't find it I report it. A couple bugs that I reported turned out to be duplicates but for the most part if a bug is reported well I find it in a minute or two. And when considering the current open bug count don't forget that many of them are 'tracking' or metabugs. There are many filed bugs that developers use to track groups of bugs (but are not really bugs in themselves). I have filed a bug against Bugzilla suggesting that there be some quick way to seperated (sort/search) the metabugs from the real bugs. There are also many bugs that have been resolved as duplicates but not yet verified. So don't take "5,000+ bugs" as a realistic count of genuine bugs. If it really takes you hours to find a reported bug then you might want to stop in at #mozillazine on irc.mozilla.org on Tuesdays (afternoon into evening) for BugDay where someone can give you some searching tips. Also if Tuesday is inconvenient feel free to stop in any afternoon or evening and if I'm there I'll be glad to help. Asa (posted with 12/27/99 win32 build -- two hours an not a crash yet) OK, I posted three of them -- one was actually reopening a closed bug. That took about half an hour, not counting account creation. Will do the rest as time allows. Ratio of testing time to bug reporting time: estimated at one to nine. That is, it will take me ninety minutes to research and report the bugs that I found in ten minutes of testing. Excellent (not the ratio of testing time to reporting time). Mozilla is getting better faster because of good bug reporting. Three of the four bugs that were keeping me from using mozilla mail and news were fixed within a week of reporting them. The fourth took about a month and a half after I reported it but performace issues are sometimes more difficult to fix than other bugs. Thank you for taking the time to report bugs. It means that _I_ get a better browser faster. Asa (still no crash yet) You're right. It does take awhile to log a good bug. But think about how long it takes for the developers to fix the bugs you find, and how much time you're saving THEM from having to research the bug themselves. This project is all about using one's abilities in the best way possible. IMO, it's silly for someone who's proficient in C++ to spend their time tracking down bugs. If we submit clear, concise bugs to the developers, then we ALL get a better product in Mozilla. That's what we all want, right? This is a collaborative effort. When Mozilla.org calls this, "The Internet's Browser," there's a reason for that. We're all helping to make it better. Don't look at the time you spend filing bugs as a bad thing, or a waste of your time. Instead, think of all the millions of people who will be using this product (including you!) who will enjoy a close to bug-free first release because of all our hard work. And if you learn how the search engine works, think of all the duplicate bugs that won't be filed, saving people's time and allowing them to work on more important things. Everyone can decide for themselves if they want to help make Moz the best browser for all platforms. But if you don't help, then an unfixed bug or a critical missing feature is no one's fault but your own. - Adam I think you missed the point. Ten bugs in ten minutes is way too many. It shows that the developers are not unit testing their code. Yes, it absolutely is the responsibility of developers to make sure their own code works. Quality if every engineer's responsibility. As for C++ proficiency, I'll put mine up against anyone else's any day of the week, not to mention Java, JavaScript, C and a host of others. What's not a good use of my time is finding other programmers' bugs, which they would have found themselves if they had spent ten minutes unit testing the code before they checked it in. Sloppy software engineering practices offend me. Buggy code offends me. Mozilla offends me for that reason. I'd like to see some pride in product there. Echinacea Feldercarb The current incarnations of Mozilla aren't finished, aren't beta, aren't alpha - hell, as far as I've seen, they don't have a proper designation yet. Therefore, I wouldn't expect the browser to work perfectly at this point. As for testing, there are releases almost every night, so you can't expect a developer to sit down, design a new feature or fix a bug, then rigorously test that feature or bug, and then get that feature or bugfix into the nightlies for everyone to enjoy. Stablity takes time. I've also found based on the testimony of others in this forum that releases will run differently under different systems. Under Windows, I found one nightly release to be act differently than the same release under Linux. I'm not sure why that is, but I'm pretty sure it's a *system* thing, not a *Mozilla* thing. I am not a coder. I hate coding. Despise it with a passion. This is why I respect anyone who can sit down and do it. I respect them even more if they can do it well. And if you can do it as well as you say, then please join the team and find a way to contribute with your skills. I'm not doing any coding, nor am I submitting bug fixes (though I should be... ^_^), but you'll also find that I'm not complaining about my browser when it doesn't work the way I want. Here's a good example: since M9, I would head to The Register and find that after the page loads, I'm greeted with a grey screen. Fine, I say - let's resize the window until it shows up. Do I expect the bug to be fixed? Not if I don't report it. Will it take time? Yes, but personally, I'm too lazy to run to BugZilla and file it. Therefore, if it never gets fixed, I'll take it as my fault and feel really bad about it. My point? You lose the right to complain about something being done badly if you have the ability to fix it yourself. Just like in poilitics - if you don't vote at all, then you can't complain when the guy you liked the least won by the vote you could've struck against him. Take the time and file the bugs. Or take the time and join the coders. Then when it doesn't work right, feel free to tell us how disappointed you are. Gee, I didn't realize you were a coder, I thought you were like the rest of us... If that's the case, don't worry about the bugs. If you're spending that kind of time finding bugs, you could spend that time writing some C and helping the development. And don't worry if you check in a few bugs (perhaps code that works on your platform, but not others)... We'll find 'em for you. :) Seriously, as previously stated, the bugs you're finding are to be expected. This is pre-alpha code, and the developers are coding to give us a final product as quickly as possible. IMO, it's best if those coders continue feverishly working on their code, and leave it to us to test on multiple platforms and find their bugs for them. That lets them concentrate on what they do best, and lets those who can't code contribute to the project. Writing well-tested code takes a lot of time, and normally you don't have a team of thousands of individuals to rely on for your bug testing. Moz is a different kind of project, and I think some of the rules are going out the window. - Adam I agree totally. It is now as it has always been, quality cannot be tested into a product. Each programmer has to be responsible for testing his/her own creation. I have personally seen the quality of a product drop when formal testing was added to the development cycle. This is of course because the "hero" programmers could now point to inadequate testing as the culprit whenever problems arose. The best way to eliminate bugs is by liberal use of birth control. Wes Ragle The program is goddamn slow on my P100 with 32MB of RAM running Win95 OSR2 without a trace of IE. its pretty slow on my P90 with 16 MB RAM. That's why I also run it on my big and fast P90 with _32_ MB RAM. :) I think that the answer to your question is that the nightly builds and M releases do not include all of the debug code but do contain some. I'm out on a limb and gessing but even just pushing messages to that mozilla console has to use some resources. I have hopes that mozilla will run at acceptable levels on my P90 with 32 MB RAM but I don't hold out hope for 16MB RAM systems. We'll see. It feels plenty fast on my PII 350 with 128MB RAM at work. #70 Isn't Mozilla supposed to be lean and mean? ntxby lord_gandalf Monday December 27th, 1999 10:58 PM ntx. My favorite bug is still that the sidebar doesn't "move" right when you drag the grippy. The grippy moves, and goes under the content, and only when you let go does the rest follow. Sometimes it dissapears entirely. Looks VERY amauterish. It has been this way for forever now, and I haven't heard anyone talk about it. Don't tell me it's going to stay this way! your friendly neighborhood MozillaZine founder and admin, Chris, reported this bug as http://bugzilla.mozilla.org/show_bug.cgi?id=19987 at one of our BugDays on #mozillazine. Check out the bug if you are interested in its progress or think something needs to be added and check out BugDay too (every Tuesday mid day to mid night USA time). under a 2.2.10 linux kernel with a "new" enough glibc: 1) proxy config from the preferences menu still doesn't work. 2) proxy config by editing package/defaults/pref/all.js doesn't work either. is this *supposed* to work now? feldercarb - I think you're missing the point somewhat. The way the open-source development model works is that everyone does what they can. While a coder should certainly code to their best ability, they are not expected or required to test things out on every platform/OS/processor combination out there. That's what the daily builds are for. Every day, you can download a recent copy of the program and submit feedback. This is very rapid, and is much more foolproof than a single person hunting down bugs on multiple platforms - at least in a case when a browser runs on a half dozen platforms at the least. As an aside, I can run M12 on my Mac (PB G3, 64 MB ram, MacOS 9) without crashing for hours - at least in the browser component, the rest I haven't played with as much. Compare this to M10 where I was crashing all of the time. It's easy to say that Mozilla is buggy because, well, it is. That's a worthless assertion though until you take into account the rate of progress. It's buggy, but it's a hell of a lot less buggy than it was only a couple months ago. The fact that you're installation was so bad doesn't mean all of ours is the same. Mozilla is a developer release. Unless you don't mind helping along in the process, don't download it. While it may seem foreign to you, it functions exactly like the average open-source project. I tend to agree with feldercarb on one point he makes. "Quality is every engineer's responsibility." I happen to think that every engineer on this project has a passion for putting out a quality product. Engineers that I've met have been _devoted_ to this task. There is a lot that still needs to be done to make Mozilla into something that joe everyman will use for his daily surfing. This is an especially daunting task when, unlike any other browser that I now of, Mozilla is being built to run on nearly a dozen platforms. Testing across even the biggest three, Mac, Linux and Windows, takes time. Feldercarb wants Mozilla better faster and sooner. I sure agree with him on that. I can't wait either. Thats why I play with a new build just about every day (some run better than others and I hold on to those). Thats why I spend time in #mozillazine and #mozilla talking about bugs and other Mozilla problems. I've managed to get my system and Mozilla both playing together nicely with the help of many developers and testers. Mozilla is pretty stable on my system and I've talked to others who have found a particular build or group of builds that work well for them. Anyone who is finding Mozilla an untamable beast is welcome to visit #mozillazine and ask for my help. Asa OK, I have finished filing the bugs. They are as follows. 1 was a duplicate of bug 14494, which had been erroneously marked closed. I reopened it with comments. 2 and 7 were duplicates of popular bug 9701, a major focus problem that has been kicking around for months. (Anyone else feel like focus problems have come to occupy WAY too much programmer time lately? I just got off a project where a quarter of all the late-game bugs must have been focus bugs. There has to be a better way!) 3 has been filed as 22761, 4 as 22766, 5 as 22769, 8 as 22771. Bug 6 was not reproducible, nor were the crashes I saw. In the course of double-checking the bugs I came across other crashes (e.g., a crash when bringing up Open Web Location) which were also not reproducible. MTBF remains in the vicinity of a few minutes. I observed a known bug, copy and paste not working in the URL bar, which would seriously impact the ability to fill in the URL field of a bug report. Total time spent following up on bugs was in the ninety minute range, as predicted. As for the current discussion, anyone who doesn't understand the importance of unit testing one's own software is not a software engineer, merely a programmer. The idea that quality software can result from delegating all bug-finding work to external parties is clearly insane, but most programmers are insane in this and similar ways. Echinacea Feldercarb With all due respect, I think you need to go reread "The Cathedral And The Bazaar." And if you still don't get it, then read it again. Only then will you understand why Linux works, why other open source projects work, and why Moz will work. They will work out of sheer software Darwinism, not because a few programmers in their ivory tower have tables of computers in which to test their code. - Adam feldercarb - Once again, I'll say this: the rules have changed. Open-source development changes the rules. Forget 'programmers', and definately forget 'software engineers'. We've got 'coders' now. These people certainly are proud of the work they do, but the real work is done when dozens and dozens of people on different platforms, operating systems, etc. do the bug hunting. Large open-source, multi platform projects like Mozilla benefit from this kind of development. And yes, it DOES work. Look at Linux, Apache, Gnome, etc. for examples. The rules have changed. Also, as I said before, your case is a fluke. I can use Mozilla for an hour or two before there are any problems whatsoever. This is on the same platform that you are on. As a fellow Mac user, I can understand how you may be unfamiliar with the open-source development process. That's 100% cool, but as the previous poster said you should read ESR's "The Cathedral And The Bazarr" before criticizing things too much. It was this document that made Netscape choose to open-source their client to begin with. You can find a link to it on Mozilla.org. I'm afraid it's you who don't understand the open source process. All the successful open source projects to date have started with a stable and unseful base laid by a small, talented, meticulous programming team, and then been able to leverage resources because people wanted to use them. Mozilla is a radically unstable base, which is why it has failed to get much outside input so far. Citing Raymond -- who, by the way, is a fanboy boob who has achieved status as the open source spokesman only because rms is certifiably insane -- is just an argument from authority. Open source is not a panacea and we are just starting to understand how it works. Mozilla is flying in the face of the models used by other successful open source products and waving open source as if it was a magic wand is not going to help address its problems. Anyway, it's obvious that this is a religious rather than a technical discussion so I'll stop hurting my blood pressure by banging on closed minds. #80 typo correction: "stable and useful base"by feldercarb Wednesday December 29th, 1999 3:41 AM typo correction: "stable and useful base". "All the successful open source projects to date have started with a stable and unseful base laid by a small, talented, meticulous programming team, and then been able to leverage resources because people wanted to use them. Mozilla is a radically unstable base, which is why it has failed to get much outside input so far." People "want" to use Mozilla, or else we wouldn't all be here. And as to the rest of your comment, the only real difference between Moz's development cycle and other projects is that you don't normally get to see pre-beta releases. You normally don't get the chance to comment on the progression of the core code base. Personally, I appreciate the candor. Sorry you see the open development process as a personal affront to your profession, but I believe this process will yield a product that more closely follows what the users want. With Moz, users have the opportunity to comment early on about features before the developers have spent too much time on them, which I think is a great thing. Mozilla hasn't failed to get input because of a "radically unstable base" of code. Actually, I think if you ask Netscape engineers, they will tell you this isn't even a true statement. They have spoken before about how outside contributors to the project have introduced some real breakthrough technology in Moz. And over time, as the code base becomes more popular (and after Communicator 5 ships, giving it major distribution), more people will become interested because they will realize this is a real project, not a dead project as Microsoft-centric magazines like to portray it. It's in a lot of people's best interests if Mozilla died. Fortunately for all of us, Mozilla engineers have a very thick skin. "...argument from authority." Well, a lot of good information is in his article, and I believe a lot of statements he makes can be proven by looking at the examples he sites. But I guess you won't believe in the model until it's been "proven," if you can even prove such a thing. I certainly don't see this as a religious issue. Let's say you've worked very hard on a piece of code, and somebody else out there in the world has a far more efficient method of doing the same thing (perhaps they recently did it for another project). With Moz's development cycle, there's an opportunity that the other developer will join in and help you. Under your method, that would never happen. To me, that's why open source is a better method. It's incredibly arrogant to believe you're such a better software engineer that nobody else in the entire world could possibly know more than you. - Adam This is not a religious debate, but rather a coding style one. I for one could care less for the 'religious' aspect of things (I'm certainly not an RMS follower, and while I think ESR is better from a more practical perspective, I tend to think for myself). I'm talking from a purely pragmatic point of view. Ever hear of opportunity cost? If the people working on Mozilla were paid to do so (which, incidentally, some are), it would cost less in the long run for those who can code to do so exclusively rather than debug, leaving that job for those who can't code but know enough to debug. Using your method, coders would produce half as much code, spending the other half of the time debugging, and everyone else who can debug will be left with less to do. Those who write the code DO debug to a limited extent, but they aren't nearly able to do as thorough job as a bunch of dedicated testers are (multiple platforms, OSes, processors, etc). Everyone does what they do best. You are also working under the false assumption that everyone's installation of Mozilla is as buggy as yours. As I've said twice already, my install under (I assume) similar hardware is pretty stable. Not up to release or even beta standards, certainly, but certainly as good as any other alpha I've played with. I'll be the first to admit that open-source is not a panacea, nor will I be one to say that anyone has a moral right to 'free' software, or even that it's perfect for all projects. However, I don't see why you discount Mozilla so quickly - once again I cite the progress it has made in the last couple of months. I don't know what's up with your build, but many of us are having no problems. Mozilla, by most accounts, has started with a small group of dedicated developers. Just like these other 'successful' open-source projects you cite. As time has gone on, interest has increased as the codebase has become more solid. Once it hits beta, my bet is that even more developers will more than happy to add on to it. I think the problem is in how you presented yourself upon first posting to this forum. Constructive feedback is fine, but you have to remember that many of the people here have contributed to the project in some way or another. It's not too far of a stretch to assume that you were insulting the programming integrity of the Mozilla engineers and everyone else who has contributed in some way to the project. All this after a single install of a pre-alpha that seems less stable than that of many others. While this may not have been your intention, the wording of your post could be construed as being inflammatory. If you are going to refute the Mozilla development model, don't simply complain - suggest a better alternative. Don't have the time to debug? That's fine, but don't blame us - I've put far more than 90 minutes into Mozilla, and it doesn't bother me a bit. Do as much as you like, and let others take the rest. While your efforts are appreciated, we'll live without them. Why is it that the milestone releases are built for Solaris 2.7, yet nightly builds are made for Solaris 2.5.1? I'm interested in a 2.6 version (and I think that the 2.5.1 version runs on 2.6). -Jason Congratulations to all the people who actively develop Mozilla,it's getting better with every build ! I was just wondering at what stage Mac development is, because I plan to buy a Mac, but can't test any builds, since I don't have one. I'm happy to see Mozilla is developing into an end-user friendly browser, rather than solely depending on standards compliance, which albeit being extremely important, won't impress Joe Average. Keep up the great work ! Well, I don't have a PC to compare M12 for Windows against the Mac version... But on my computer (PowerBook G3), M12 is shaping up to be a pretty nice product. I don't use it for "real" work yet (I still use Communicator 4.7), but I can keep it running for a lot longer without it crashing. M11 had major redraw bugs on the Mac version; most of these appear to be gone on M12. I can only imagine each successive build will become more feature packed and crash less. I think my biggest complaint about Moz on Mac is the violation of Apple's HIG standards. There are many places throughout the application where HIG does not need to be violated, yet it is anyway. My hope is that over time, the developers decide to look at platform UI differences the same way they do "skins," and make more platform-specific customizations to make Moz "feel" more like a platform-native application. If you're buying a Mac to run Moz, I wouldn't suggest it YET. If you're buying a Mac for iMovie or Final Cut Pro, or because you want a nice computer to do your work on, go for it. :) (I'm a Macintosh consultant, so if you have any questions, feel free to send email -- not in this forum, obviously.) - Adam |