Mozilla 0.9.3 Released!Thursday August 2nd, 2001mozilla.org today released Mozilla milestone 0.9.3, continuing to work towards a 1.0 release. Preliminary data is showing that 0.9.3 is up to 35% more stable than 0.9.2, thanks to increased focus on stability bugs this milestone. Along with that, the newest incarnation of the Modern has had some additional work since 0.9.2. ... just checking for the release notes of 0.93, but I am getting an error 404. The build however downloads fine :-) n/t As of 0.9.2 www.bmo.com and www.cibc.com , two major banks stopped working. They work with 0.9.1 and pre-june21 builds still. What's up, nobody cares? There was a bug report and it isn't assigned to anyone The CIBC bug is: http://bugzilla.mozilla.org/show_bug.cgi?id=87440 There's been activity on it as recently as yesterday so some attention is being paid to it. Although, disturbingly, one comment was made that it wasn't a "real" bug (should go to Evangelism) and that CIBC should have to change their site. This is in dispute, however, so hopefully Mozilla will get patched in the end. Since I only use CIBC I haven't been following the BMO progress and I can't comment on that one. Jason. although cibc claims hey do not support netscape 6, it used to work flawlessly since I began using Moz for ssl/https in 0.7 so it must be something in Moz that broke. There's no question that something changed. The debate seems to be whether it changed for the better or worse. My take on it (although I don't know any of the technicalities involved so I'm by no means an expert in what's happening), is that the argument goes that that Mozilla standards have been IMPROVED since 0.9.1 and that while it worked before it did so at the expense of a security problem. Now that Mozilla's security in that area has been fixed it exposes a problem with the banking site. So, it isn't that Mozilla was working, then broke, but rather that it was broken before (and the banking site shouldn't have worked) and is now fixed. Whether or not that is true remains to be seen. Personally, I just want to be able to do my online banking with Mozilla again! <grin> Jason. It might be a TLS problem (SSL version problem). I'm quoting the release notes for 0.9.2: The Secure Sockets Layer (SSL) protocol defines rules governing authentication between a web site and browser software and the encryption of information that flows between them. The Transport Layer Security (TLS) protocol is an IETF standard based on SSL. TLS 1.0 can be thought of as SSL 3.1. [Mozilla/Netscape 6.1] supports both SSL and TLS. Some servers that do not implement SSL correctly cannot negotiate the SSL handshake with client software that supports TLS. Such servers are known as "TLS intolerant." When you select the "Enable TLS" option in the SSL preferences panel, the browser will attempt to use the TLS protocol when making secure connections with a server. If that connection fails because the server is TLS intolerant, the browser will fall back to using SSL 3.0--with one important exception: If you are using a proxy for SSL connections, the browser will not attempt to use TLS at all. Instead, it will attempt to use SSL 3.0. (Bug 88244) FYI, Although CIBC still does not work with 0.9.3 - it DOES work with build 20010803 based on the 0.9.2 branch. YMMV with the BMO site - I don't know. Jason. But... under financial snapshot it causes the browser to crash every time. Hope they can tell what the problem is from the talkback. Now that a new Moz is here, will we see a new netscape (preview) release soon?? I hope so. 0.9.3: nice, no problems so far! good work! Including www.mozillazine.org. Had to refresh to get the proper formatting. Same thing happened on www.news.com. Refresh fixes it. See bug 82720 (http://bugzilla.mozilla.org/show_bug.cgi?id=82720) How can this be? According to Mozillaquest, .9.3 should have come out months from now ... with its 3000-14000 bugs... Asa, blizzard, timeless, and others, surely you must be mistaken, for such use of bugzilla will sure show your lack of bug testing and "sweeping under the carpet" .... what BS... http://www.newsforge.com/article.pl?sid=01/08/02/0432247&mode=thread FWIW, I've sent an email to newsforge and linuxtoday about their linking to mozillaquest ... CRAP like this will only hurt mozilla and XP browsing on the web ... please do your part to help. Test bugs, and mozilla.org, keep rocking! I don't know what drugs Mike Angelo is on, but he's clearly one obsessed person - banging on and on about the number of "bugs" (which I suspect he is mis-counting, particularly since many "bugs" are just enhancement requests) and the delays in the release schedule. Since Mozilla has no commercial deadlines (yes, there's indirect deadline pressure from AOL/Netscape for their Netscape 6.X releases), the constant rant about missing deadlines is pretty laughable in my books. Also, who is to say that the number of bugs in such a large project as Mozilla isn't typical of most similarly-sized projects ? What are the number of bugs in MSIE for example ? Oh, that's right, it's a closed source project that has never and will never admit how many bugs it has. And as for "sweeping bugs under the carpet", that's almost libellous. The bugs have NOT disappeared - they've been retargeted for a later release. It's always better to fix a proportion of the targeted bugs quickly (and correctly of course) and release a new version, than to try to fix every single targeted bug (which would add weeks to the release schedule and have Angelo in a rabid release-delay frenzy, so you can't win either way). I have no problem with one or two additional milestones (0.9.5 is looking likely now for example) before the 1.0 release to make sure that all major or worse bugs have been fixed. Let's put it this way - Mike Angelo is the Steve Gibson of the Mozilla world (has the same taste in bizarre Web site design too :-) ). From a personal point of view, I consider progress in Mozilla to be: 1) it crashes less, 2) it misbehaves less, 3) it runs/starts up faster and 4) it uses less memory. Almost every milestone so far has managed to fulfil these criteria (Angelo conspicuously fails to comment on these criteria - his "release comments" are purely rants about the number of bugs and release delays and nothing about what it's like in "real world use"), which shows that the Mozilla team are making very good progress with each release. If Angelo was to be believed, the product is becoming *more* unstable because it has more "bugs" - the exact opposite is true. http://bugzilla.mozilla.org/reports.cgi?product=Browser&output=show_chart&datasets=NEW%3A&datasets=ASSIGNED%3A&datasets=REOPENED%3A&datasets=UNCONFIRMED%3A&links=1&banner=1 This is a graphical picture of a similar issue to the one I mentioned. This one includes both targetted and untargetted bugs, lumping serious problems in with trivial typos and enhancement requests and without any indication of severity; as such it is of somewhat limited value. The problem with both this and the statistic I mentioned is that they are subject to the "lies, damn lies, and statistics" criticism; without more information it is difficult to know what they mean. Both of them are worrisome however. I tend to think that the one I mentioned is more so, because those bugs have presumably been deemed "worth" fixing in a relatively short time frame and to be of a fairly severe nature, and this graph presumably includes lots of duplicates, enhancement requests, and trivial errors. You can even argue that to some extent, getting a lot of user reports can be something of a good sign, as long as they aren't reports of lots of different problems of a serious nature; it means that people are actually using the program. I really haven't seen much discussion of this, other than that "it seems more reliable" at the end-user level. This is good, no doubt about that, but then what is the meaning of the continuing upward tick in the open/targetted bug counts? Does anyone with enough information to talk intelligently on this care to comment? Bruce To be fair, try http://bugzilla.mozilla.org/reports.cgi?product=Browser&output=show_chart&datasets=NEW%3A&datasets=ASSIGNED%3A&datasets=FIXED%3A&datasets=REOPENED%3A&datasets=UNCONFIRMED%3A&links=1&banner=1 Adding the number of fixed bugs to the chart is just a feelgood measure. It doesn't change the fact that the number of known defects in the system is continuing to increase. I didn't much care for that metric either. It's good that a lot of bugs are being fixed, but if you're still being outrun by "incoming" it won't help much with progress towards 1.0. At some point you have to start fixing more than you're finding or you'll never reach closure. ... Assuming that all (or even many) of these are unique errors, of course. To the extent that they are things like enhancement requests and duplicates the raw numbers _may_ be misleading. However if many of these "new" bugs are duplicates it indicates that the QA team may be being overwhelmed even if the coders may not be. Still not a good sign. --Bruce Compare the slopes of the lines. This is not a "feel good" measure, it's a metric of what's getting accomplished. More bugs are being found, and more are being fixed, and the number of bugs being fixed is increasing at a much higher rate than the number of bugs being found which aren't yet fixed. Your metric is probably dependant upon the complexity of the code - the more complex the code, the greater the number of unfixed bugs, regardless of how good a job the developers are doing. As bcwright pointed out, and as anyone who's been associated with shipping a professionally QA'ed software product knows, the important thing about the slope of the line is whether it's increasing or decreasing. All defect lines in every defect state for Mozilla are increasing. So you are suggesting that if a product has no critical, highly visible, broken functionality issues but does have 4 trivial, edge case, polish-needed issues that it is worse than that same product a month ago when it had 3 critical, highly visible, broken primary functionality bugs?! You're over simplifying this to the extreme (and so am I to make the point). You also assume that because the total bug count is growing that the total number of bugs in the product is growing. This is a broken assumption especially in large and complex pieces of software where all bugs are not known on the first day. Feel free to scream 'feature creep' but you're also leaving out that there are scores of major features which did not exist at the beginning of the project and do now. With new code you're likely to have new bugs. There is nothing wrong with that. In a hypothetical simple product it we knew that a list of 3 critical defects was the complete and definitive list of all existing problems in the product and a month later we had 4 critical defects in that product and we knew that list was the definitive list of all existing problems then I would agree that a change from 3 to 4 would be a bad sign. If the 4 defects were the same severity as the previos 3 then this would suggest that the product was regressing rather than progressing. But this isn't the case. We do not and have never had a complete and definitive list of all of the problems in the product. No project of this size ever does. We are, however, getting closer to knowing most of the important problems. To go back to my earlier example, if our simple project was a week old and we knew of 3 bugs which had existed since the beginning of the product and a day later we discovered a 4th bug which had also existed since the beginning of the product it cannot be said that our quality is worse because of the discovery. In this case our quality would not have changed at all, we would just have a better understanding of it. In the same example, if we had one feature with 3 bugs and we added another feature of equal complexity and value and this new feature had 2 bugs bringing our total to 5 bugs it isn't fair to say that the product has regressed. In a project this large it is probably impossible to know all defects in the product. I believe with the 15,000 active bugzilla accounts and the hundreds of thousands of Milestone and nightly downloads which result in 100 to 300 new bug reports a day that we will get as close to knowing all bugs as is possible in a project this size. One year ago I was seeing about 35% of incoming bugs resolved as Duplicates. Six months ago about 40% of the bugs reported on Mozilla were Duplicates. Today it looks like over 50%. I expect to see this trend continue until the vast majority of reported bugs are Duplicates. When we aren't finding any new bugs except regressions then you can say that an increase in the slope is a bad sign. Until then we're actually improving our Quality by identifying more of the problems rather than less. Identification of problems in existing code helps to prevent the addition of problems in new code and helps identify areas of code which are better served with a total rewrite rather than lots of smaller patching. The closer we approach all known issues the better off we are. Mozilla has been wildly successful compared to all other major open source projects (and probably most closed projects) when it comes to broad testing and issue reporting. We could have just as well not opened Bugzilla to the world and would probably have about half of the open bug reports we currently have but we'd still be just as buggy, probably considerably more so. We have a higher quality product than we had 2 years ago, 6 months ago, 5 weeks ago. For example, as a percentage of the not duplicate, invalid and worksforme bugs filed in the first half of 2000 compared to the not duplicate, invalid and worksforme bugs filed in the first half of 2001 the number of blocker, critical and major bugs has dropped and the number of minor, trivial and enhancement bugs has grown. There are more known issues in Mozilla but the severity of those issues is definitely lower than it was. Ad-hoc testing and anectdotal evidence (read slashdot's story on 0.9.3 and compare that to 0.9.2 or 0.8) suggest that product is considerably better than it was a year ago. Our MTBF has doubled in the last 3 months, you can read about it in the talkback reports posted to the newsgroups. The number of users being affected by our topcrash bugs is plummetting. We have important new features like LDAP addressing, offline mail support, bi-di hebrew and arabic, automatic proxy configuration, and much more that all happened this year. We not only have a much more complete feature set but fewer important bugs in those features and any suggestions that an auto-generated graph of bug counts in our database proves that our product is getting worse is absurd. If you have specific and concrete suggestions about how we can improve the process of making this product better please send email to asa@mozilla.org (bugzilla and QA/Testing issues,) staff@mozilla.org (larger project process issues) or drivers@mozilla.org (code issues) and I'll do my best to see that those suggestions are discussed. Posts to mozillaZine.org discussions full of vague and misleading interpretations of bug data doesn't help make anything better. --Asa > We could have just as well not opened Bugzilla to the world and would probably have about half of the open bug reports we currently have but we'd still be just as buggy, probably considerably more so. I like that. Watching the testing and development of such a large project isn't a frequent opportunity. I feel lucky for being able to do so. But I think more effort must be consumed in quality indicators like severity, priority and the keywords. Some bugs are 4xp or major or regressions etc without being masked as such. Many bugs are marked normal while they are minor or even trivial. In the past, I tried to make such suggestions (in specific bug reports). But I concluded that it would make more noise (bugzilla database growing and becoming less usable, as you had sometimes pointed out) than good. Maybe it's a human resource (triagers) problem, after all. "But I think more effort must be consumed in quality indicators like severity, priority and the keywords. Some bugs are 4xp or major or regressions etc without being masked as such. Many bugs are marked normal while they are minor or even trivial." Priority and Target Milestone belong to the developer. Any help keeping Severity http://bugzilla.mozilla.org/bug_status.html#severity settings up to date and accurate is a big help. Adding keywords http://bugzilla.mozilla.org/describekeywords.cgi where appropriate is also very helpful. If you're interested in helping to keep this kind of information up to date and accurate in Bugzilla please let me know (asa@mozilla.org) and I'll try to get you set up with a particular component or developer that needs help in this area. --Asa #129 Re: Re: Re: Re: Re: Re: Re: bugs? what bugs? i seeby bcwright Tuesday August 7th, 2001 8:24 AM Asa makes a lot of good points about the problems with using a crude metric like the raw bug count - these are some of the reasons why I distrust that metric. At best it's a crude bellweather that closer study may be needed to make sure that there aren't serious process problems, but it's not by itself indicative of such problems. The comments about the increase in the proportion of bugs that are resolved as Duplicates are also very positive; it is probably an indication not only of knowing more of the population of existing bugs but also of increasing popularity of the program and would be consistent with increasing quality. I still have concerns about the number of bugs targetted for fixing before 1.0, especially the number marked (Major | Critical | Blocker). That number will have to start decreasing at some point or you'll never reach closure. That may mean starting to refuse some things in those categories that effectively amount to enhancements, and/or making a concerted effort to correct serious defects even if it's at the expense of other enhancements or trivial bug fixes. My personal experience and recommendation is that defect removal, especially of serious defects, should take precedence over enhancements. It's usually more useful to have something that works well and reliably than to have something that's flakey but has more features. Granted that the distinction can be difficult to make at times - if you're in a Right to Left environment (Hebrew, Arabic, etc), the lack of BIDI can feel like a defect, but if you're not then that may feel more like the addition of a not very useful feature. But my observation is that the project sometimes appears to get too tilted towards the "new features" rather than towards true "bug fixes." On a brighter note, my experience with 0.9.3 so far has been very positive. This is the first milestone that seems very reliable given my browsing habits. It hasn't crashed on me yet, which is very good considering that my habits cause IE to crash several times a day and Netscape 4.7* and Mozilla 0.9.2 and before several times an hour. By "crash" I mean any kind of abnormal termination, including program lockups, not merely OS reboots. It appears to indicate that things are starting to head in the right direction. Keep up the good work guys, and try not to get sidetracked on too many "interesting" features. Feature creep and sidetracks can be the bane of any software project. --Bruce We could consider these possible additional explanations: - Installed base has been increased since Mozilla becomes more and more usable. - Because of the vast improvement in the quality of the application, more people are starting to use it as their *primary* bowser. This would reveal more minor bugs. He is a jackass. We all know it. He say stupid things to rile us all up, and that drives hits to pathetic site. Let's just leave him alone. There are some concerns about the recent trend in the bug count however. Without more extensive analysis it's difficult to get a good feel for what the raw numbers mean, but the number of open entries that are marked "blocker", "critical", or "major" that are targetted to be fixed for 0.9.3 through 1.0 has slowly risen over the last month from about 500 to (currently) about 539. There are several possible explanations for this: 1) More bugs have been identified that were always there. 2) More enhancement requests in those classes have been added for inclusion in 1.0. 3) There have been a lot of regressions over the last month. 4) Some of the bugs may have been split into two or more component bugs in order to better reflect the underlying issues. 5) Some bugs may have been upgraded from less severe categories into the more severe categories. Only choice #3 indicates that there may be a problem with declining code quality; choice #2 may mean that the "second system" management problem is starting to add bells and whistles for inclusion faster than they can be written (a worrisome issue since it potentially can make the march to 1.0 stretch out into an arbitrarily long time). The other possibilities are basically administrative, but _may_ indicate that the original target was more ambitious than originally thought and may take longer to achieve. If the project is to achieve closure on 1.0 then it will be necessary to get a handle on this. What would be required to do so depends a great deal on why the list is growing faster than bugs on it are being retired (and a lot of them are being retired, as can be easily verified). Does anyone who has more familiarity with the open bug list than I do have any comments on this (asa)? Bruce "3) There have been a lot of regressions over the last month... "Only choice #3 indicates that there may be a problem with declining code quality" All regression bugs should have the "regression" keyword. There are 2500 bugs http://bugzilla.mozilla.org/buglist.cgi?keywords=regression containing the "regression" keyword in total. A Bugzilla query for NEW, ASSIGNED or REOPENED bugs containing the "regression" keyword filed between June 1st 2001 and now came up with 96 bugs http://bugzilla.mozilla.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&email1=&emailtype1=substring&emailassigned_to1=1&email2=&emailtype2=substring&emailreporter2=1&bugidtype=include&bug_id=&changedin=&votes=&chfield=%5BBug+creation%5D&chfieldfrom=2001-06-01&chfieldto=Now&chfieldvalue=&short_desc=&short_desc_type=allwordssubstr&long_desc=&long_desc_type=allwordssubstr&bug_file_loc=&bug_file_loc_type=allwordssubstr&status_whiteboard=&status_whiteboard_type=allwordssubstr&keywords=regression&keywords_type=anywords&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&order=Reuse+same+sort+as+last+time and a similar query for bugs filed between April 1st 2001 and May 31st 2001 brought up 69 bugs http://bugzilla.mozilla.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&email1=&emailtype1=substring&emailassigned_to1=1&email2=&emailtype2=substring&emailreporter2=1&bugidtype=include&bug_id=&changedin=&votes=&chfield=%5BBug+creation%5D&chfieldfrom=2001-04-01&chfieldto=2001-05-31&chfieldvalue=&short_desc=&short_desc_type=allwordssubstr&long_desc=&long_desc_type=allwordssubstr&bug_file_loc=&bug_file_loc_type=allwordssubstr&status_whiteboard=&status_whiteboard_type=allwordssubstr&keywords=regression&keywords_type=anywords&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&order=Reuse+same+sort+as+last+time - draw from that what you will. Alex So, assuming this information is accurate and people have been scrupulous about assigning the keyword, the number of regressions has increased by about 40%? That would seem to be in line with the Reopened line, http://bugzilla.mozilla.org/reports.cgi?product=-All-&output=show_chart&datasets=REOPENED%3A&links=1&banner=1 , which the QA cognoscenti often use as a metric of overall system stability, and which is closely related to regression rate. Yes, that concerned me too. Another way of looking at it is that the increase in the number of regressions probably accounts for a goodly percentage of the increase in bugs marked "major" or above and targetted for being fixed before 1.0 (although not all of it), which is a measure that I think I trust a little more than the raw count. Though there are games you can play with that number too. Unfortunately I can't quite figure out how to look at this number over time. Bruce BTW what happened to 0.9.2.1 ? I never saw anything announced on mozilla.org or on MozillaZine 0.9.2.1 is supposed to be the non-branded version of their 6.1 release, IIRC. Yes, just like mozilla 0.6 was build on the same branch as Netscape 6.0. But I was just wondering why it was never announced. IIRC, 0.6 was a delayed release that didn't hit until about when/slightly after 6.0. Thus 0.9.2.1 shouldn't be released until Netscape is done with 6.1. Startup is speedy, pageloading is speedy, looks good, works! I knew Mozilla would get better, but so soon and so much better!!! Whoa! Good work, people! It's at least as fast as opera. Since Mozilla 0.9.1, Java is just not working for me. The situation continues in 0.9.3. I have tried to load various applets that used to work fine in the 0.9 release but I keep getting the following error on every single one of them: java.lang.ClassFormatError: [Applet Name] (Truncated class file) I am behind a firewall at work. Might this have something to do with it? At home I don't seem to have this problem. Something must have changed since 0.9. Does anybody know if there is some sort of fix or work-around for this. I am using JRE1.3.0_01 and my operating system is WinNT 4.0 SP6. I hope this will be fixed soon ;-) For the rest, I am pretty happy with 0.9.3 :-) Gerdinand Looking at the message, it seems to me to be an internal java problem with the applet. the error implies that the java code can not be understood by the Java interpreter. The firewall shouldnt cause this. Log a bug in bugzilla or post here and be as specific as possible about what applets fail, what build numbers fail and which work, exact error messages, operating system, computer platform, etc. Download JRE 1.3.1 here http://java.sun.com/j2se/1.3/jre/download-windows.html This version is not the same as 1.3.0_1 that Netscape for some reason keeps shipping. The installer for 1.3.1 now detects Netscape 6. I don't know if it detects Mozilla. comment the Sleep-Statements out? use Trans-Warp technology? Emulate a Flugs-Capacitator from back to Future to roll bac time while rendering? It's "flux capacitor" dammit! I have a 200Mhz Pentium 164MB RAM running Windows 2000. When I compare the speed of page loading between IE 5.5 and Mozilla 0.93, I've found that the overall loading time is still won by IE. On Mozilla there actually is a 2-second delay before the page start appearing. Undoubtedly Mozilla renders the page much faster than IE. However IE let the user view the page quicker. What is Mozilla actually doing during that 2-second or so latency? Anyone can tell me? I'm just curious. Thanks. Godric Yeah, Mozilla always has a slight delay before opening new pages. It used to be maybe 1.5s on my PII 400, but now it's much less. It's still noticeable though, especially vis-a-vis IE 5. Rendering's much faster though! It just pops up on Mozilla, while in IE it plods along. The Win32 full installer isn't available yet. When you download it, you get the stub installer instead. why is mozilla-win32-0.9.3-installer.exe 213216 08/02/01 07:11:00 pm file the same size as mozilla-win32-0.9.3-stub-installer.exe 213216 08/01/01 05:38:00 pm file Shouldn't the installer be larger, like 8.5MB Both from home and now from work the full installer gets to the downloading phase and freezes. Some network problem I guess. I'm downloading the 10MB tarball just fine though. Anyone else seeing this this morning? I love it :) I've been actively promoting Mozilla since 0.8 at least. We're well on track to a 1.0 release! In the announcement on mozilla.org's front page, it says: "Talkback data shows that recent 0.9.2 branch builds are more stable than Netscape 4.78." I'm not sure that Talkback reports are really a good measurement of stability. I get a lot of crashes where the Talkback module is not run. Or is it just me? apart from that: i think talkback will capture crashes that occur with medium to low frequency realistically. But assume there are really nasty crashes: people will immediately stop using Moz - no more talkbacks. So those statistics are just plain wrong. I am talking of really nasty crashes that only occur with certain users, configs, or in certain situations of course -- high frustration crashes. Bottom line is that talkback data is fine, but developers shouldnt stop to listen to people whining and complaining :) Read the comments from http://slashdot.org/articles/01/08/03/122222.shtml Lot of positive feedback. I already use Mozilla as my main browser. Good job guys! Just installed 0.9.3. Installed the same way I always install mozilla. Running RH6.2 Runs fine as root. Crashes with SIGSEGV at first URL entry for non-root. Any ideas? read the release notes. If you want to run Moz under different users you have to install it for every user... :( I have a 200Mhz Pentium 164MB RAM running Windows 2000. When I compare the speed of page loading between IE 5.5 and Mozilla 0.93, I've found that the overall loading time is still won by IE. On Mozilla there actually is a 2-second delay before the page start appearing. Undoubtedly Mozilla renders the page much faster than IE. However IE let the user view the page quicker. What is Mozilla actually doing during that 2-second or so latency? Anyone can tell me? I'm just curious. Thanks. (one of my sample page is cnn.com) Godric I believe the developer made mozilla wait few second before start to render. To limit the reflow a bit, it help improve the performance I believe. Mike Does anyone know where I can find a higher resolution, or (hopefully) a vector based version of that pic? I think it would look so damned kick ass on a t-shirt, that and the commie-moz-star... Have a look at http://www.mozilla.org/projects/svg/ - it contains the image you're looking for, in SVG format. You'll have to draw the star for yourself, though :-) Well, it seems good so far, no crashes or anything, and pages do render with amazing speed. (faster than IE on my computer even with the tiny inital delay --1ghz pIII 256 meg ram -- in fact it is even faster rendering a reaload side by side with IE when I start IE's reload first -- this is IE 6 preview, btw) My first annoying thing is that it started with the classic interface, which to me is, well, ugly. ;) Not that it's a big thing... it's easy enough to switch... however, the one thing that is bad enough to make me keep using IE is that the scroll-zone feature of my touchpad doesn't work in mozilla. On 'tall' web pages, it is extremely annoying to have to go back and use the scrollbar constantly. I'm not sure if the problem is in the touchpad software or mozilla, but either way, it is 'not cool!' (actually, it may be because the way the scrolling is accomplished is by temporarily moving the cursor to the scrollbar and moving it up or down based on your movements, so perhaps it doesn't work with the 'non-native' scrollbars in mozilla) Anyway, though, it is very stable and can render sites that cause IE to stop functioning (www.skiutah.com). At any rate, I really think mozilla at this point could be my primary browser on my desktop, but not quite yet on my laptop. I suppose that's it... keep up the good work! Scott The scrolling is a problem with Mozilla in your case, and mine as well. This is most likely the bug you are talking about. http://bugzilla.mozilla.org/show_bug.cgi?id=22775 Like you this is one of the main reasons thats keeping me from going to Mozilla permanently. The sad thing is I don't know if Autoscrolling will EVER be implimented, as the person who was assigned this bug 8 months ago, has seemingly made LITTLE OR NO progress at all. If you're talking about the Synaptics touchpad driver not doing autoscroll, that's easy enough to fix. Edit your SynTPEnh.ini, and add the following block: [Netscape Navigator/Communicator] WT = "*Mozilla*" SF = 0x10000000 SF |= 0x00004000 That worked for me. Well that's obviously wrong. Seems like mzine doesn't honor linebreaks in posts. [Netscape Navigator/Communicator] WT = "*Mozilla*" SF = 0x10000000 SF |= 0x00004000 .. and remove the blank lines Well, after a quick restart of my computer, it worked! :) :) :) :) ;) Thank you very much for this.... I think I'll use Mozilla as my main browser now! Thanks again! Scott Does anyone else notice the weird lines behind the links on the toolbar until you mouseover them? (they remain on any part that doesn't have links, as well as between the home and bookmarks buttons) Scott Yes I have this problem too. Actually it seems to depend on the browsers width. Try resizing the browserwindow in small steps. Some sizes looks right, some don't. It' s abug 80292 Black hash marks in the personal toolbar for modern. Go to http://bugzilla.mozilla.org/show_bug.cgi?id=80292 for details. There is a patch waiting for review I have been using Mozilla much more than Internet Explorer for a while now. I have managed to handle the terrible start time. The problem that bothers me the most is every time the browser crashes, the history list is lost. That could drive me crazy if I was forced to use Mozilla. Nobody is gonna believe me, but I find it weird to read about mozilla crashing so much, I can't remember Mozilla crashing (gpf) for a very long time. It's win98se so it probably needs rebooting to often or something.... I install nightlties about twice a week. I keep my windows installation pretty clean, maybe that helps. I get crashes quite a bit, probably at least once a day of heavy browsing. The most annoying thing is that sometimes when I try to reload mozilla after a crash, it takes like 5 minutes before the window shows up. Anybody know what that's all about? And the worst part is that my harddrive gets filled up with all these ~40mb core dumps! BTW, I'm running Mandrake 8.0 + X4.1 Generally, I find that it is Win9x that's causing the crashes, and not Moz's own fault, at least that's what I found from NS4. NS4 used to crash daily on my win95 machine, even after a clean install. Then I switched to win2k about 1 1/2 years ago and it's only crashes two or three times ever since. So I guess it could be the same thing for Moz. Maybe, just *maybe*, win9x just sucks.... Windows 98 does not cause Internet Explorer to crash on my computer. Mozilla crashes almost daily. When I tried to install it on Windows NT Server, it crashed on startup. I saw the TalkBack thing before I saw the splash screen. I do not think people should try to justify this problem by blaming it on Windows. The history list is important. No other browser destroys its history list when it crashes. Quarkness, do you think Windows destroys the Mozilla history list too? I just tried to submit a bug at bugzilla and I found it impossible, I just couldn?t understand how the thing is supposed to work. Could someone do me a huge favour and enter one for me please? It's regarding the site http://www.thedvdforums.com/forums None of the images on the first page of the forum are showing, this means that you can't post a new message because the image for that button doesn't show and that goes for the buttons that represent other features of the forum. You also cannot tell when new messages have been posted either. This has only been a problem from milestone 0.9.1 onwards. Many thanks. KAC. KAC, it's not that hard. try the helper at http://www.mozilla.org/quality/help/bug-form.html --Asa I just installed 0.9.3 and it seems great except for one problem. My friggin View menu won't show up! Someone already filed a bug on this fortunatly. http://bugzilla.mozilla.org/show_bug.cgi?id=93621 This seems like a rather large bug that is extremely annoying. It wasn't showing up in 0.9.2 or in 2001072703. I'm not really familiar w/ the workings of Bugzilla, is it appropriate for me to comment on that bug just to confirm it? I would say it is, since no-one else has been able to reproduce it yet. Just post a comment saying that you get the same problem. Remember to say that you're using 0.9.3 and include your platform and OS. You'll probably want to add yourself to the CC list as well. Alex I had this same problem when I installed 0.9.3 over the top of 0.9.2. I uninstalled and then reinstalled and everything work greats now. Try uninstalling and reinstalling and see if that works. Has anyone else noticed the enormous amounts of RAM that Mozilla is eating up? I am running 0.9.3 and after opening only four different windows and viewing a couple pages Moz has exceeded 38 megs! The speed that the pages redraw when scrolling a tall page is pretty bad too. Overall it's looking good, but there needs to be a bit more effort looked into some things. Cheers, -Jon So, what's 38 megs to you if you have 256? Surely, the remaining 218 megs haven't been eaten up my something else? Besides, what does 512 megs cost these days anyway? They're practically giving it away for free... Of course, less footprint would be nice, but I don't see how the footprint is really a big problem anymore Arnoud I only have 128MB Not everyone has so much memory :( A lot of endusers are still stuck with slow computers, y'know? "So, what's 38 megs to you if you have 256? Surely, the remaining 218 megs haven't been eaten up my something else? Besides, what does 512 megs cost these days anyway?" When you want to deploy Mozilla on 1000 workstations in an organization, suddenly RAM costs 1000 times more. Footprint matters. Jason. about $240 NZD. I've noticed that it's the windows resources that gets chewed first before I run out of memory. And yes I am running 512Mb of RAM and no I didn't buy it recently and yes things do run better under Windoze with more RAM. But Linux doesn't care most of the time. Also I noticed that the memory footprint doubles when I go to a secure site and that sometimes doesn't get unallocated because when I exit Mozilla, sometimes the PSM stays, as another Mozilla.exe program running in BKG. I've noticed actually the weight of that footprint on my swapfile after all my Mozilla windows have closed... and the tray icon is still running. Big fat chunk of memory, even when the only Mozilla thing running is the tray icon. Ironically, when I kill the tray icon, I get back about 25MB of swap file. (I'm running on a Win95 w/ 32MB of memory... yes, yes, I know it's half the minimums Moz "requires", but it works for me...) I found Mozilla has strange, inconsistent ways of using memory. On my work computer (PIII 600, 128MB, win2k), Mozilla often eat up to 50MB of memory after a few hours of browsing, forcing me to shut it down and restart. On my laptop (Celeron 500, 192MB, win2k), I visit the same sites for a few hours, but Mozilla keeps itself under 30MB. Does anyone know what's going on? There are many memory leaks here and there. Most of them haven't been identified yet, imho. But the worst of them, a leak when composing mail in modern theme http://bugzilla.mozilla.org/show_bug.cgi?id=93393 was fixed immediately after 0.9.3 release (you have to downlad a "nightly" from here http://ftp.mozilla.org/pub/mozilla/nightly/latest/ ). There is also a network cache which increases footprint, proportionally to the rate of sites being loaded I suppose. Again, I don't understand why it shouldn't stop occupying new memory. If you want to know how much memory a WinNt/2000 process is using, read the "Virtual Memory" column, not the "Mem Usage" column. From the Windows task manager, the "Virtual Memory" column indicates how much memory the process actually needs (AKA "Private Bytes" in PerfMon.) The "Virtual Memory" column isn't enabled by default. The "Mem Usage" column (AKA "Working Set" in PerfMon) indicates how much physical RAM the OS has set aside for the process -- You'll notice that this value drops to nearly zero if you minimize the window. If you have lots of free RAM, this number will greater than the Private Bytes. OTOH, if you don't have lots of free RAM this number will be less than the Private Bytes, meaning that some of the process's memory has been swapped to disk. In other words, a high "Mem Usage" reading just means that you've got lots of free RAM, and is not an indication of how much memory the process has alloc'd. I use Mozilla as my primary browser at work; it typically sits between 18-22 MB all day. How would one turn on the "Virtual Memory" column in Win2K? >>How would one turn on the "Virtual Memory" column in Win2K?<< Dunno about Win2k, but in NT 4 you start the Task Manager, then go View->Select Columns and tick 'Virtual Memory'. I've made the download of Mozilla 0.9.3 to my Mandrake Linux 8 computer. Every thing work perfectly except the plugins. My plugins that i had in use in Mozilla 8 version aren't recognize. So i don't have flash player working, the Real plugins don't work and finally my java plugin doesn't work too. The same problem occured in Netscape 6.1 PR1. Anyone with this problems You probably missed something, because I have the same configuration as you and everything is working fine : Flash, Realaudio, Java and even all those plugins together... Hey, you guys want a *real* test of rendering speed? Check out the popular gaming site http://www.planetquake.com/ Mozilla's incremental rendering really shines on this site, Opera doesn't show anything for several seconds, and IE is just plain slow. You're right there. Isn't Gecko great? It's a shame that the page isn't standards-compliant - on IE you get nice drop-down menus when hovering above the GameSpy navigation bar (at the top). For a comparison, I tried loading the page in Netscape Navigator 4.78. The less said about that the better... Alex Umm.. I'm not sure what you wanted to prove.. I'm currently encoding an mpeg1 file from my friend's bachelor's party and it's sucking up about 95% of the CPU usage and STILL IE 5.5 SP1 loaded AND rendered that page in about 2 seconds, most of which must have been loding time. Resizing the page reflows in realtime without any noticable slowdown or stuttering. I'm on an Athlon 500MHz with 128 megs of RAM and Win2K. I'm not commenting on Mozilla here in any way, but if this was your test to show that IE was "just plain slow", you failed miserably. Try using a dial-up connection. On my 56Kbps modem the page takes about a minute to load in both IE 5.5 and Mozilla 0.9.3. However, Mozilla shows some content straight away (and reflows and shows more as it goes along), whereas IE doesn't show anything until right near the end. Alex >I'm not commenting on Mozilla here in any way, but if this was your test to show that IE was "just plain slow", you failed miserably. > Athlon 1.33mHz, 256 meg RAM TNT2/64 video, cablemodem: Page loads in: (after flushing cache) Mozilla 0.93 .... 1 second IE 5.5 ......... 4 seconds NC 4.78 ......... 7 seconds I noticed that the new autocomplete seems to behave differently than it did back in NS6: Even when "Location bar autocomplete" is turned on, it doesn't actually complete it inline, but merely puts up a drop-down with the possible matches, requiring you to arrow down to pick the one you want. I much preferred the old behavior, where it put the best match inline, and if it was right, you just needed to hit 'Enter'. Does anyone know if this was an intentional change? This was changed by design. The new autocomplete's pretty cool (check out those page titles!) but I liked the inline completion. There's a debate in bug 78268 http://bugzilla.mozilla.org/show_bug.cgi?id=78268 about bringing it back. Alex God, does anybody have any clue as to how many CSS bugs are still out there? Has Hyatt finished the CSS rewrite yet? Ugh. >:( Shacknews can't finish downloading because of it.http://www.shacknews.com/ Anyone else think there are way too many options on the right click tabs and menu options? Too much clutter IMHO. I'd like to see a simple Mozilla mode with have that crap disabled. :( I'm also getting quite tired of seeing my IE favorites folders not in Alphabetical order! A then B then C then D, get it? Not B, then C, then D, then A! Can't even do numeral numbers right too. God I'm sick of this. The Bookmarks Manager is a total piece of shit. Nice sorting options, but you can't permanately save them that way. I'd like my bookmarks sorted by name thank you. *closes out of BM & checks bookmarks menu* Aw crud. Would be nice if there were some nice icons for the BM too. :) Yeah, I know that I'm picking on Ben Goodger again about this stuff. :) So do I have anything good to say about Mozilla 0.9.3? No. Waiting for Multizilla to be released. It'll actually make Mozilla useful for once. :) > God, does anybody have any clue as to > how many CSS bugs are still out > there? Has Hyatt finished the CSS > rewrite yet? Ugh. >:( Shacknews can't > finish downloading because of (LINK) Hmm, does finish loading on my machine (Win98SE). ANd looks ok besides the rightmost "Todays News"-header image (the one above the authors email adresses). "Anyone else think there are way too many options on the right click tabs and menu options?" See bug 75338 http://bugzilla.mozilla.org/show_bug.cgi?id=75338 Alex Actually, my rant would be with Internet Explorer for not allowing me to sort my bookmarks the way I want them but instead always sorting them alphabetically. In Mozilla you get to drag your bookmark into exactly the place you want it when you add it, not so for IE. Probably Mozilla is listing the IE bookmarks in order of when they were added (the Mozilla default). You are right that it would be nice to have the option of sorting the bookmarks alphabetically for IE users who have gotten used to having them listed that way, so we can save the time of manually moving them into alphabetical order, but in general I like the Mozilla way better than the IE way here. Actually, my rant would be with Internet Explorer for not allowing me to sort my bookmarks the way I want them but instead always sorting them alphabetically. In Mozilla you get to drag your bookmark into exactly the place you want it when you add it, not so for IE. Probably Mozilla is listing the IE bookmarks in order of when they were added (the Mozilla default). You are right that it would be nice to have the option of sorting the bookmarks alphabetically for IE users who have gotten used to having them listed that way, so we can save the time of manually moving them into alphabetical order, but in general I like the Mozilla way better than the IE way here. We've had a 'stability' milestone. A 'UI polish' milestone might be nice, if merging in 0.9.2.1 isn't sufficient. I've been using 0.9.3 for win32 since last night. It feels flakier. Nothing I can quantify yet. Well, maybe a couple of things: 1. A few times today, I've loaded a new page and seen the name of the *previous* server in the status bar (as in 'Connecting to ...'). 2. Trying to quit from -turbo. Kill the app with File->Quit ... um, no. Go to 'Exit' on the systray icon. Whoops, musta picked the wrong 'Exit', because Task Manager still shows a mozilla.exe holding on to 60MB memory. (Though I did set my memory cache to 32MB.) Kill it there. *Now* it restarts. 3. Some flakiness (after several hours running) in opening new windows by Javascript (using Outlook Web Access). The restart mentioned in 2. seems to have fixed it. 4. A window that decided to stop responding to the keyboard at all. Other Mozilla windows were fine, but this one just didn't care ... (For 4., it should be noted that I have messed with the chrome a bit, changing the Ctrl-Q for Quit to Ctrl-Shift-Q, as per Bug 52821 http://bugzilla.mozilla.org/show_bug.cgi?id=52821 . Dunno how fragile that chrome is.) Is anyone else seeing the above? I suspect I'll be giving 0.9.2.1 a go when it shows up - presumably Netscape will have done a *lot* of work on polish. And I will eagerly await said changes being merged back in :-) I've seen #1 pretty commonly. I've seen it with not only the previous server, but a server from a different window! For #4, I get this too...pretty rarely though, and I haven't messed with chrome. Yeah. When I said "can't quantify yet," I meant well enough to, e.g., write a bug report. If I can get one to happen semi-repeatably, I will. Still, I've only been beating on it for one day. Let's see what today brings ... >>When I said "can't quantify yet," I meant well enough to, e.g., write a bug report.>> It's happening again - 3. then 2. (flakiness in Outlook web Access, then the app won't die until killed from Task Manager). Dammit, I'll be writing a bug if there isn't one already. #127 Re: Re: Re: 0.9.3 flakiness - others' experiences?by thoffman11 Tuesday August 7th, 2001 5:38 AM Now that you mention it, I have seen that flakiness w/Outlook Web Access. I sometimes have to reload the window a couple times in order to open a message. >>Now that you mention it, I have seen that flakiness w/Outlook Web Access.<< Considering that Outlook Web Access is from Microsoft, I suspect they're not susceptible to evangelism :-) In older Mozilla milestones, OWA wouldn't work at all for me (0.8.1 and before) or only work partially (0.9 on). It pretty much all works in 0.9.2, and one learns to live with the hiccups. Seems to work okay in NS 4.7x. However, a page shouldn't be able to beat the browser into that condition. So I think it's a reportable bug. Maybe I'll have time today ... Should probably mention it on the newsgroups too. I have had none of the symptoms you described above, but my 0.9.3 (win98) crashes every time I open MailNews. Has anyone else experienced this? I've seen #2 since Mozilla 0.9.2. See my post in netscape.public.mozilla.performance. Nice to know someone else has seen the same behavior I have. File a bug, please, and e-mail me the bug number. I know this is a bit off topic but I wanted to tell you all that Netscape 6.1 is released... http://ftp.netscape.com/pub/netscape6/english/6.1/ The folder appears to be empty. But I've read about the release on BetaNews http://www.betanews.com/ and ActiveNetwork http://www.activewin.com/ so I guess it must have been released and then pulled. On the other hand, there's talk on the Netscape 6 newsgroups of a new 6.1 beta that people may be confusing for the final 6.1. But then there's posts that suggest it was a misunderstanding and that the real 6.1 is out. I'm really confused now. Alex From a snews://secnews.netscape.com/netscape.netscape6.windows comment by Jay Garcia: "Netscape TESTS the ftp server by uploading the app for a few hours. Consider yourself 'lucky'. 6.1 has not been "officially" released yet." Just have to wait then. Alex I'm getting it on the Netscape homepage. So does it have a bunch of polish fixes like some people here were anticipating? Nothing astonishing that I've seen. But they must have done some polishing, because ToyFactory is buggy in Mozilla in a way that it's not in Netscape 6.1 (the scrollbar displays, well, sideways in Mozilla). When I leave Moz on for a long time (usually overnight), when I start using it again after the hiatus, after a few minutes, all components of Moz become unresponsive, and I have to restart Moz. Even after restarting Moz, the problem often recurs. Has anyone else been troubled by this? Oh, and milestone releases are supposed to have optimised code vis-a-vis nightlies. Just how much is the optimisation? It doesn't seem to be that much to me. " milestone releases are supposed to have optimised code vis-a-vis nightlies. Just how much is the optimisation? It doesn't seem to be that much to me." Milestone builds are no differenly compiled than nightly builds. Nighly and Milestone builds are --disable-debug & --enable-optimize. You shouldn't see any performance difference between the branch nightly the day before the release and the Milestone release. --Asa "You shouldn't see any performance difference between the branch nightly the day before the release and the Milestone release." ? The branch nightly the day before the release refers to the nightly just before a milestone release? Yes, if I understand your question. We have a development trunk and we make builds off of the tip of that trunk usually twice a day for about 5 platforms (resulting in about 40 nightly trunk builds). When we get close to a Milestone we create a branch for some stabilization work and let the trunk race ahead. The branch might be actively developed for days or weeks leading up to a Milestone release. We usually don't take major changes on the branch so the nightly builds from the branch right before the release are very close, code-wise, to the actgual release. Nightly branch builds as well as nightly trunk builds are build optimized with debugging turned off. All binaries you get from ftp.mozilla.org are "release" (meaning optimized and not debug) builds. --Asa On my Win98/128mg, I have not been able to use Moz 0.9.3 for 15 minutes without a crash. It crashes every 5 minutes on average. I really enjoyed 0.9.2, so I am very disappointed for now. Just so everyone knows. I've built k6 optimized rpms of mozilla-0.9.3 and they are available on my site. http://k6-rpms.sourceforge.net Jonathan I am very happy with Mozilla 0.9.3, it works very fine for me. But I have a question, is there any plan fon impanting the css2 property text-shadow, and in this case, when? Best regards and keep up the excellent work! |