Mozilla 0.9.6 ReleasedTuesday November 20th, 2001mozilla.org today made available for download binaries of the Mozilla 0.9.6 Milestone. The builds are available on the releases page, or you can get them directly from the ftp site.
Nothing on mozilla.org, no posting in n.p.m.announce, still over 100 unresolved bugs targeted to 0.9.6 and 5 bugs in the "make 0.9.6 not suck" tracking bug. Has this milestone really been released? PS: Posting this with the nightly from 11/19, which seems to be working quite well. Announcement is up now. I guess Mozillazine has the inside edge on reporting milestones. :-) Hehe, if you weren't in the know, you'd think Mozillazine was independent from Mozilla.org :0 Er, what? Well, most of the contributors here are mozilla.org contributors or drivers. And Asa maintains the wonderful buildbar :) Basically this is just for peripheral Mozilla-related announcements/news and community discussion outside of the more-stuffy atmosphere of the mozilla.org site Er, no. Asa is the only mozilla.org person who works on the site, and he's been doing it longer than he's been working for mozilla.org. Ooops :) You learn something new everyday. Well, this site *does* get a lot of inside scoops, hmm? Like just now's posting of 0.9.6's release You work for Netscape and so will be close to the major developments in the mozilla world as Netscape is the biggest contributor. However, I think this is a good thing, it means that Mozillazine.org is reliable source of info. Then we've got Mozillanews.org for rumours and Mozillaquest.com for total crap #25 Re: Re: Re: Re: Re: Re: Re: official announcement?by Tanyel Wednesday November 21st, 2001 7:33 AM ...and Tanyel for the things all three of them missed. The original question has not been answered: what about the bugs targeted & tracked bugs? There are still 103 critical bugs targeted to 0.9.6 and 4 for "make 0.9.6 not suck' tracking bug (12037, 105619, 106445, 109356). What is the plan for these bugs, are there going to be pushed to 0.9.7? Some of them are topcrashers. Or perhaps the plan is that some commercial version is to be based on 0.9.6, so that the branch will go on until these critical bugs are closed, and we might see an update for 0.9.6? I doubt as I didn't see any keywords for that. I don't understand the process anymore. Can someone explain what's going on? #28 Re: Yeah, what about the bugs (and performance)by unapersson Wednesday November 21st, 2001 8:04 AM Its the same as its always been. Bugs are targetted towards a milestone and as many are fixed in that time period if possible. If they can't be fixed in the alloted time they're move back to a later milestone. Its not complicated, you just have to remember that the milestones are *targets* that the programmers are aiming for. Its not always possible to fix every alloted bug before a milestone, and if they were held up until every single bug on the target list was done the milestones would never come out. They're meant to be frequent releases that can be tested by a wider group of people than the nightlies. Blame me for being slow, but a week or so ago I finally saw the pattern (if there is one) 0.9.2 - Netscape 6.1 0.9.4 - Netscape 6.2 0.9.6 - Netscape 6.3? 0.9.8 - Netscape 6.4? 1.0 - Netscape 6.5? The numbering is pretty nice, it all fits in well, with the fabled 1.0 release (wah!) as Netscape 6.5. My bet, and I am just guessing, is that they'll wait until 6.5 for the next release, and use 1.0 as a base. I thought that after 6.1, though, and have been proved wrong once already. Personally, the more they release the better. It seems each version of Mozilla that's released contains snazzy new features that I NEEEEED. JR http://home.netscape.com/themes/6_2/index.html it doesn't work in a recent nightly (can't check cos it crashes before it opens a window, something like 2001111303) mangelo's stuff ain't there no more, and mozillaquestquest is apparently down? Anybody got the scoop? Well, just checked the infamous mangelo, and noticed a definite proof of copy-pasting (ok we already knew he did that, but there it's laughable) on the download links, it's written "0.9.5 downloads", and then something like "here's moz 0.9.6" and then links to go to moz 0.9.5, etc. I hope MozillaQuestQuest will make such an article with unchanged bits of previous articles ;) #12 Clumsyness Has Article Out on a Limb -- And Questby ipottinger Wednesday November 21st, 2001 2:48 AM Clumsyness Has Article Out on a Limb -- And Quest in Limbo Newest Article Released Ian Pottinger -- 20 November 2001 (c) A certain site released its latest attempt at producing an informative article earlier today. Nevertheless, it failed, again. A clumsy desire to post an article as soon as a milestone is released had the pre-fab article out on a limb, and the site's quest in becoming a mozilla news source in limbo, for the past ten days. The latest article was likely composed using cut-and-paste sometime last week. More about that further down. First here is what is new in the latest article: * 1,334 words (only 1 misspelt) * 52 paragraphs * 0 infomation based on a review of the milestone More statistics and links are in the Resources section at the end of this article. Meanwhile here is what happened to put this article out on a limb and delay the site's quest in becoming a mozilla news source. The article was somewhat clumsy and probably contained numerous spelling and gramatical errors. So, it is not surprising that it was not released last Friday when it was likely first composed. Nor is it surprising that the article was not released until today. As we go to press so to speak, the spelling errors count for the article has been whittled down to 1. That's right folks. The article was released with 1 spelling error still within it. On the one hand, it is important to release articles while they still represent "news." On the other hand, it is important to present informative reviews based on actual experiences with the subject before releasing that article -- even if it means a delay in releasing the article. To the author's credit, this article contains a vastly reduce number of factual, gramatical, and spelling errors, though only likely due to its equally vast lack of content. It is possible that there exists an error tracking memo titled *make new articles not suck* that point to numerous repeated errors that the author particularly wanted to avoid before releasing this article. However, since neither the author nor the site privides for reader comments or feedback, this can not be verified. The article did not appear until this past Tuesday, 20 November -- only hours (if not minutes) after the latest milestone release was anounced. That seems somewhat flaky. It just adds to the confusion, chaos, and turmoil in the site's quest in becoming a mozilla news source. This sort of clumsy posting of pre-fab articles containing no infomation based on actual use of the milestone puts the article out on a limb. This in part is the reason we believe that this site's quest in becoming a mozilla news source is in limbo as stated in the title of the article. Ab uno disce omnes, mozilla news sites depends upon reader feedback to help improve article quality. Readers cannot offer their comments or suggestions until such features are made available on this site -- or if they have the desirability and resources to contact the author directly. Earlier today there were nearly 1,735 words (1,734 words to be exact) within this latest article. Those all are words that the author say should be consided informative content. However, with more than 400 words religated to the "resouces" section and the rest being mere number comparisons with on real analaysis, the informative content currently listed in the article is nil. (The copyright notice contains only 10 of those 1,734 words -- but it's another chunk off that big word count.) Following past practices, the author created this newest article by copying from a previous one. Then he merely presented it under a new title, so to speak, by pasting then performing a few global-replaces in order to try to produce an informative article. Please see our 0.9.4 branching article, New Article Released -- Quickly & Less Inforative Than Ever, for more detail and information about the site articles. Stay Tune #15 Re: Clumsyness Has Article Out on a Limb -- And Quby ipottinger Wednesday November 21st, 2001 3:00 AM Okay, so I got sloppy towards the end. It's late but I just had to do it! Why? Because it has become a mozillazine tradition :-) Fear not, it's back up. How could we live without his bitter, distorted and Badly Misinformed (tm) website? There is -one- thing I like about MozillaQuest and that's why I go there even though I don't like the articles: the bug count in the front page. Why don't we have something like that? I would also be nice to have a graph showing the evolution of these figures. Then I wouldn't need to read this crapy site everynow and then. > the bug count in the front page. Why don't we have something like that? Because the bug numbers are considered embarrassing, and any reference to the direction the bug curve is taking is grounds for being branded an idiot. Repeat after me: There are no bugs. Everyone is doing a great job. There are no bugs. Everyone is doing a great job... Yeah! It’s really despicable the way mozilla.org try to cover up their bugs by hiding them in their publicly accessible bug tracking database with easily generated bug reports! oh... wait a minute... #66 Re: Re: Re: Re: What happened to mozillaquest.org?by strauss Wednesday November 21st, 2001 3:30 PM >> the bug numbers are considered embarrassing, and any reference to the direction the bug curve is taking is grounds for being branded an idiot. > It’s really despicable the way mozilla.org try to cover up their bugs by hiding them in their publicly accessible bug tracking database with easily generated bug reports! I was referring to the screaming that ensues here whenever anyone mentions the defect curve's continual upwards climb, as well as the abuse directed at mangelo for citing bug figures from Bugzilla in his articles. I made no claim that the bugs or the number of bugs were hidden, only that there was an informal social pressure to cover up their significance. The only problem with the defect curve and with writing about it is that there's just no way for easily displaying it. I know about the reporting utility but there's no use if bugs like "Tracking bug for interesting bug reports" or "We need a complete feature list of Mozilla" is treated absolutely equal to a "Mozilla destroys my system". And even if you could select just blocker or critical severity bugs there's still the problem that this severity is subectively set by the enigneer. Statistics is Voodoo. That's the hole problem. You already can select just blocker or critical bugs in bugzilla. However you've hit the nail on the head when you say that severity level assignments can be very subjective, and that things like tracking "bugs" [sic], documentation "bugs" [sic], and minor enhancement "bugs" [sic] can't be meaningfully equated in importance with the "Mozilla destroys my system" bugs. Add to that the fact that in any large software project, you can often organize a class of problems either as one big "bug" or as a separate one for each instance. Is this one "bug" or a lot of them? Are the underlying problem(s) any worse if you organize the tracking tool as separate "bugs"? Stylistically some bug reporters may choose one method or the other; it's very difficult to impose absolute uniformity. Now add in all of the duplicate reports of the same bugs which may take a quite a while for QA and/or the developers to determine are actually the same bug, and that the number of reported issues will probably become greater as more people use the software (many of which will be duplicates or trivial enhancement requests or simple errors on the part of the users) ... it can be a difficult subject. As someone said, there are lies, damn lies, and statistics. ... which doesn't mean that the statistics are necessarily meaningless, but it does mean that focussing too strongly on the raw counts can be treacherous. You really need to have a fairly intimate familiarity with what's in the database and how likely or reproduceable or severe each item is (apart from the claims of the report, which may be inaccurate), and because Mozilla is so large I doubt that there are very many people who do outside of those who work for Netscape and other companies who are paying people to devote large amounts of time to the project. This makes it hard for outsiders to judge exactly what the situation is. As an outsider, the thing that concerns me most about the project is not the raw bug count, but the "off in all directions at once" tendency that makes serious regressions likely. I would rather see what's already there made to work really well and reliably rather than lots more minor features. Once that's done, you can always add the features later. --Bruce Another problem with the idea of a "defect curve" is that ignores the fact that as time goes on, bugs tend to become more specific. For example, the links toolbar was one general bug about the need for implementation. Then once the links toolbar was implemented, there were immediately half a dozen or more bugs filed on how to improve it. Since then there have been several more links toolbar related bugs filed. Since there are now several links toolbar bugs instead off one, does that mean that Mozilla is worse than it was before the links toolbar was implemented? The whole concept of an increasing Mozilla "defect curve" is flawed. Anyone who believes that this "defect curve" is a signifigant issue is an idiot. Anyone who thinks that more bugs listed in Bugzilla equates to Mozilla being in worse shape is an idiot. Anyone who is an idiot should not be surprised when someone calls them an idiot for saying idiotic things in a public forum. > Since there are now several links toolbar bugs instead off one, does that mean that Mozilla is worse than it was before the links toolbar was implemented? Yes, it does. You still seem to be having some trouble grasping the concept of feature freeze and the quality impact of adding new features. It's a pretty simple concept, and familiar to anyone who has released software of any significant size, so I'm not sure what the problem is here. Er, so, when we go into feature freeze, we should stop taking enhancement bugs? Just because it's in bugzilla, doesn't mean it will happen. That's not the point. The point is that new features consume resources for testing the features, and if serious errors are found will require resources to find and fix the bugs. Note that "serious errors" in this context are NOT further enhancement requests unless they are enhancements that are practically required for the useability of the feature. One of the major principles of software development is to get rid of the "serious defect" problems as soon as possible (crashers, dataloss, producing incorrect results, etc) AND THEN you can add new features if you have time. Otherwise the project is likely to get totally out of control. And as long as you're adding new features you are making it more difficult to obtain closure on the "serious defect" class of problem. How difficult depends a lot on the exact situation, what sorts of features are being added and so forth, but it's not unheard-of for this to make it *IMPOSSIBLE* to obtain closure. --Bruce Whose point are you referring to? The point I was referring to was Strauss' point about 'feature freeze' and adding new features. New features always pose a risk of regressions and getting bogged down in side tracks, which may not matter as much (and even be necessary) during earlier stages of development, but become a serious schedule risk and liability as you get closer to a final product. That's the whole point of a 'feature freeze.' I really don't want to get bogged down in a discussion of whether this feature or that feature caused serious regressions -- that's really beside the point. If it didn't, then that's great! But the problem isn't any specific new feature, it's the cumulative risk from all of them. Again, sometimes the risk is necessary, as when you find that feature X (already in the product) is really not very useful without sub-feature Y, and feature X is necessary for final shipment. Then you are practically forced to add sub-feature Y. Or perhaps you have some major customer who has an absolute requirement for feature Z, then you may need to seriously consider adding that feature if you want to keep that customer. But you need very good justification for adding anything as you get into the late stages of a project, because the risk to your schedule of adding features at that stage is substantial. --Bruce The problem is that you are very adept at replying to a single line of my post and then changing the subject. I do not have any trouble grasping the concept of feature freezing a development project, but that is irrelevant; my post had nothing to do with feature freezing -- it was all about the defect curve red herring that you seem to like to throw about. My point was specifically about the fact that an increase in the number of bugs does not mean that the product is worse than it was before. I chose to use the links toolbar as an example because none of the current links toolbar related bugs are critical, blockers, or crashers. Before the links toolbar was implemented, we had a signifigant hole in compliance with W3C specs represented as one bug. Now we have a functional links toolbar filling that hole, but we have several bugs filed about cleaning up and improving the implementation. The browser is better with an imperfect links toolbar than it was with no links toolbar despite the fact that it caused an increase in related bugs. It is a pretty simple concept that I expressed very plainly in my previous post, so I'm not sure why you had a problem addressing the subject as it was. Perhaps now you can respond without pretending that I was talking about something different? #74 Re: Re: Re: Re: Re: What happened to mozillaquest.by joschi Wednesday November 21st, 2001 5:33 PM acutally, most people give very level headed, in depth explanations of how broken his math is. You just choose to ignore those posts. #78 Re: Re: Re: Re: Re: Re: What happened to mozillaquby strauss Wednesday November 21st, 2001 7:41 PM > acutally, most people give very level headed, in depth explanations of how broken his math is. You just choose to ignore those posts. I haven't seen such a post. I do my own Bugzilla searches and they give the same results that his articles and bug bar do. What I see here is a lot of ranting and raving about what an idiot he is, and how the bug curve's continual upward climb doesn't really matter, and why it doesn't matter that hundreds of bugs targeted for each release are postponed until the next release. Those are the posts I choose to ignore. I never see a reasonable, clear-headed treatment of his articles, which vary greatly in quality. They often suck -- I just posted my own parody of his copy-n-paste style a few days ago -- but some of his articles are very reasonable and detailed. They provide a welcome counterpoint to the rah-rah boosterism of MozillaZine. Ideally we'd have something in the middle, but that has yet to emerge. #82 Re: Re: Re: Re: Re: Re: Re: What happened to mozilby bcwright Wednesday November 21st, 2001 8:37 PM I don't think I've seen a single post that claims that his bug counts are wrong. The arguments against Mangelo's methods that have been posted here can be summed up in two words: Sampling error. Now we can argue about whether this should be called a math error or not ... it's certainly debatable but ultimately irrelevant. Naturally this implies that if this is so, that there is a good deal of what amounts to trash in the bugzilla database. Or at least sufficiently heterogeneous objects that his analyses do not have the significance that he attributes to them. This idea doesn't particularly surprise me, especially given such a large collection of heterogeneous entries maintained by such a large number of people over such a long period of time. --Bruce #85 Re: Re: Re: Re: Re: Re: Re: Re: What happened to mby strauss Wednesday November 21st, 2001 11:09 PM > I don't think I've seen a single post that claims that his bug counts are wrong. I have. I've responded to one this month. When I pointed out the numbers were correct and gave the search links to demonstrate it, the claimant simply fell silent. > The arguments against Mangelo's methods that have been posted here can be summed up in two words: Sampling error. That applies somewhat to the overall counts, but it applies considerably less to the bugs that are targeted for specific releases, which have presumably been reviewed. In addition, it is not much of an excuse to say that there are a lot of unclassified, junk, and duplicate bugs in the database, because that means (as you note above) that it is hard for anyone to know what the actual situation is. Actually you said it was hard for outsiders to know, but I doubt there is anyone, inside or out, who has much of an initimate familiarity with some fifteen thousand outstanding bugs. To me this seems to indicate that the bug database is not a very useful tool for understanding progress toward the goal, which is a very dangerous situation -- it's like flying with no instruments. Late in a project's life cycle, the defect lines are the main tools for guiding the project. Nonetheless, there are some metrics which seem to bear on reviewed bugs, and so are somewhat more reliable, although the actual situation might be worse than these measures indicate because of unreviewed bugs. One is bugs targeted at a specific milestone. One expects some of these to slip, but the slip numbers are large, in the three figures per build. Another is the bounceback rate, that is, the reopened bug line, a standard indicator of overall system stability. That just continues to climb at about a forty-five degree angle. (Actually there is a decline in the last month, but it's within the line's normal wiggle -- still, it may mean that the feature freeze is having some effect.) So the indicators that are more reliable seem to be saying pretty much the same thing as the overall bug numbers, which is that the stability situation is not under control. If I were in a position of QA authority on a project with these metrics, my first priorities would be to get all the bugs reviewed and to do a root-cause analysis to understand the reopened rate. When I suggest those things here, well, you see the kinds of responses I get.... #95 MZ readers are actually right about bug countsby leafdigital Thursday November 22nd, 2001 3:28 AM I just did a graph for new/confirmed/assigned bugs vs. fixed bugs, and the fixed bug curve appears to be growing more rapidly than the assigned bugs curve. So what's the problem? (I may have done the wrong kind of graph here, first time I used that tool, in fact I was assuming that the bugs would be going up much faster than they are being fixed/resolved, so...) More to the point, the browser's pretty much reliable (unless you happen to download a bad nightly, of course), so what's the problem? I mean seriously... the fact is that the more people use Mozilla, the more bugs will be reported (whether those are actual bugs or feature requests). The increasing bug count just indicates that more people are testing the browser. So, to reiterate: what's the problem? Bottom line: the browser is a much, MUCH better product now than it was a year ago, even though I'm sure the bug count has dramatically increased (doubled?) during that time. And yes, I do use it all the time. Conclusion: a higher bug count does not mean a worse or less stable browser. I agree that a more balanced news source would be useful, but on this issue there's no doubt: during the last year, when the Bugzilla bug count has increased dramatically, Mozilla has finally become a stable, quality browser. Last year, when the bug count was much lower, Mozilla was a less-stable browser that was missing many essential features. Using the bug count to indicate anything about quality of a browser is ridiculous, just as it was ridiculous to imply that because Win95 shipped with 1,000 known bugs (or whatever it was) it was an awful, buggy operating system. Mind, it *was* pretty buggy :) but every product ships with bugs, and the number of them depends more on the quality of testing than the quality of the software. The fact that it was probably many of the same people who are now saying on mozillazine that bug count doesn't matter, who were previously crowing about the high bug counts in released MS products, is irrelevant; they're right this time, they were wrong before. They may be right for the wrong reasons (unbridled Mozilla support with no recognition of its disadvantages) but they are still right. --sam #115 Re: MZ readers are actually right about bug countsby bcwright Thursday November 22nd, 2001 10:17 AM >More to the point, the browser's pretty much reliable (unless you >happen to download a bad nightly, of course), so what's the problem? The point is that even though the quality and reliability may be improving, if the project could get a better handle on bug tracking, review, and scheduling while avoiding regressions, the quality would improve faster. --Bruce #123 Re: MZ readers are actually right about bug countsby strauss Thursday November 22nd, 2001 12:56 PM > I just did a graph for new/confirmed/assigned bugs vs. fixed bugs, and the fixed bug curve appears to be growing more rapidly than the assigned bugs curve. So what's the problem? Well, that's not how it works as I understand it from my experiences working with QA as a development engineer. You will note that the 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 new, assigned and reopened lines are all increasing. That means new bugs are being filed faster than bugs are being fixed, and that supposedly fixed bugs are being reopened faster than they are being reclosed. It may be that a lot of the new bugs are junk bugs, as has been suggested, but if they haven't actually been reviewed and closed as duplicates, non-bugs, non-reproducible, etc. then there's no real way of knowing if that's true or just wishful thinking. As has been pointed out here several times the lines are not very reliable metrics because the incoming bugs are not getting the attention they need to classify them properly, but in the absence of a better metric we have to rely on the one metric we do have, and that is not an encouraging one. When a product is on a release track, these lines start to move downwards. That's a generally accepted industry practice. On a large software system it's hard to say exactly what an acceptable bug count is, but it's easy to say what an acceptable bug trend is, and that's downwards. > during the last year, when the Bugzilla bug count has increased dramatically, Mozilla has finally become a stable, quality browser. Last time I tried it, it crashed on me and threw away a half hour of work I had put in on a message, and I was then told that there were no useful MTBF ratings for my platform. I haven't tried again, especially since I'm still seeing very mixed reports here. We're still seeing major regressions in both nightlies and milestones, especially in the areas of form elements and text fields. It has gotten better but it's by no means stable. I believe it is true that the relative severity of bugs has declined, but a non-crasher like text fields being too slow to keep up with an average typist is still a big problem. > Last year, when the bug count was much lower, Mozilla was a less-stable browser that was missing many essential features. It's the slope of the lines rather than their magnitude that is most important, and the slope is pretty much the same now as it was then. The assigned bug line has flattened significantly, which is good even though there's no progressive flattening, but the new bug line has actually gotten much steeper. It's very important to the product to make whatever structural changes are needed to get those new bugs reviewed -- this should be a top priority of the drivers. Another should be to find out the reasons for the very disturbing reopened line http://bugzilla.mozilla.org/reports.cgi?product=Browser&output=show_chart&datasets=REOPENED%3A&links=1&banner=1 . That's one of your postings where I can agree. There is no real way of determining a useful defect curve out of Bugzilla. The only things that can be pulled out are very raw estimates which may be plain wrong. And you may be right when you say that this is like flying with no instruments. The only way currently to set goals and measure the progress against this goals are the tracking bugs like the Mozilla 1.0 tracking bug which is something but maybe not enough to control such a large project. Nevertheless Mozilla is getting better, that's what I say as a user. If the feature freeze now happens ans all focus is done on reducing real bugs and improving performance and stability I see a glory future for the lizard :) But the feature freeze must be done to get a real stable base where features can be added later. Have a look at these Bugzilla issues. I think they could provide some "instruments" that help reflect the overall status of the project in the statistics. As usual, patches are welcome. http://bugzilla.mozilla.org/buglist.cgi?bug_id=9412%2C65965%2C75172 Separating out enhancement requests would be useful, especially for generating better bug charts. I wish them luck with the idea of a feature request tracking system -- it's a very hard problem and even most mature research departments have a hard time maintaing this kind of forward-looking intellectual property in a useful form. You know how hard it is to write a good product specification? Tracking possible future product directions is pretty much the same problem, only squared. #120 Re: Re: Re: Re: Re: Re: Re: Re: Re: What happenedby bcwright Thursday November 22nd, 2001 11:20 AM >To me this seems to indicate that the bug database is >not a very useful tool for understanding progress >toward the goal, which is a very dangerous situation -- >it's like flying with no instruments. Bingo. >One is bugs targeted at a specific milestone. One expects >some of these to slip, but the slip numbers are large, in >the three figures per build. If you look at the way bugs seem to get targetted, the tendency seems to be to just make a wild guess that maybe we can fix this by such-and-such a date. There is little effort to spread out or prioritize the bugs over several milestones; they tend to get lumped into the next available milestone. This is oversimplifying of course, but that's the tendency. When the inevitable happens and not all of them get fixed for that milestone, they just get moved to the next one, and so forth. Naturally this implies that the number of bugs targetted for a specific milestone has little meaning - it's more of "a wing and a prayer." Now how important this is depends a lot on what kind of bugs these are and what the endpoint target is (both in time and in features and stability), and also whether the bugs that are actually fixed fit into the range required to meet that target. A milestone isn't the same as a release, but to the extent that the bugs that get pushed back are serious defects (as opposed to minor defects or new features), it can make it more difficult to control the project. The amount of effort to correct a defect is often difficult to predict, since it will involve tracking down what's causing the problem and then devising a solution. Often the time is heavily weighted towards tracking it down. Adding features is much easier to predict, you usually don't have that big initial cost and can go directly to designing the feature. If you have too many real defects you'll lose control of your schedule. Not that any of this should be news to you but it might be to anyone who hasn't been involved with it before. >Another is the bounceback rate, that is, the reopened >bug line, a standard indicator of overall system stability. And this is the most worrying indicator of all, but you never see it mentioned on Mozillaquest. Instead he is almost totally focussed on the overall bug counts and the number of bugs targetted for each milestone, which aren't very useful figures given the way that mozilla.org uses bugzilla. --Bruce " One expects some of these to slip, but the slip numbers are large, in the three figures per build" What does "in the three figures per build" mean? So you're saying that fixing 1,600 or so bugs in a milestone and getting to the end of the 5 week cycle (these are _milestones_, checkpoints, oportunities for talkback data from a larger base, etc) with one hundred or even two hundred of the bugs targeted at that milestone unfixed means something? When nearly 200 individual developers set target milestones indicating that they'd like to fix some set of bugs for a particular milestone and don't get 100 percent of them fixed then our project is in jeopardy? If a developer says he's going to try to fix 15 bugs this week and we get to the end of the week and he's only fixed 13 or 14, you call that problem? I don't. I'd love for people to be a little more realistic when estimating what they can have fixed when but so long as the number of bugs actually fixed each milestone is predictable (and it is) then I'm not too concerned that some people are a little too ambitious. If we had targeted 1500 bugs at 0.9.6 and then fixed 1600 would we be better off than if we targeted 1700 and 0.9.6 and only fixed 1600? (the real story here is a bit more complex. we actually target about 2000 bugs at a milestone and fix about 750 of those plus 850 or so that weren't at the time (but may have been at one time) targeted at that milestone. nothing prevents someone from fixing a bug that hasn't been targeted yet or that is targeted at a later milestone. this could all be better and it would make my job managing the releases a bit easier if it was more accurate but it has very little to do with the actuall quality of the product and nothing to do with "the stability situation".) Can you do me a favor? Go get M10, then M11, M12, M16, M18, 0.7, 0.8.1, 0.9.1, 0.9.3, 0.9.5 and 0.9.6 (feel free to get all the milestones but for my purposes this should be a good sample). Run M10 and use it for an hour or so. Then run the next for an hour or so. Then the next. When you get to 0.9.6 post a comment here telling me that we're not getting better with every milestone. If you can also include detailed explanations of how the product is worse now than it was in any of those previous milestones that would be helpful. I've been using Mozilla since before mozilla.org was providing binaries. I've been using it as my exclusive browser since M8 and as my exclusive mail client since M10. I use the browser and mail client about 8 of my 12 hours workday. I notice when things get better and I notice when they get worse. I don't usually test nightly builds on the weekends but I've used and tested the overwhelming majority of weekday nightly builds for the last 3 years. I admit to being a Mozilla advocate but I'm also a user and there aren't many (if any) users that have logged more hours on more builds than me and, while some critics aren't, I'm very comfortable saying that it's getting significantly better with every milestone. There aren't many that have logged more time reading and triaging bugs in Bugzilla either. You can throw all the numbers you like at me and you can point to mangelo's counts or the bugzilla graphs. You can talk about the rising lines and the different curves but you won't convince me that we're not getting better all the time. My experiential knowledge flies directly in the face of the numbers and lines you're so fond of mentioning here. I suspect that many others who respond to your posts here are coming from a similar place. We use the product and we _know_ it's getting better so when you and mangelo say that your graphs show it getting worse, we ain't buyin' it. I don't know about you but mangelo admits to not using the builds, not even the milestone builds he's 'reviewing' at his homepage. I do use the builds. I've used thousands of them on more platforms than most. Not only have I used mozilla builds but I've used mozilla based products coming from other companies making similar and completely different products. I've talked with developers, qa and users of other mozilla based products. I'm about as on top of the state of the code and the products coming out of it as anyone can be. You're not. Mangelo isn't either. There are a lot of people (millions of them) using mozilla and mozilla based products and the reviews and comments at mainstream journalism outlets like c|net, in newsgroups, bug databases, mailing lists, weblogs like mozillazine and slashdot, etc., all suggest that the product is getting better (even, suprise, "good"). I'm not denying that many of the lines are going up in the bug graphs (even "fixed") but I am disputing your statement that the product "stability situation is not under control". I've got the mtbf numbers, the user reviews and comments and the direct experience to back that up. You've got some counts of entries in a database made by over 16,000 different people. (did you know that the average number of people experiencing our 'topcrasher' bugs is going down at the same time as the number of people using our nightly and milestone builds is going up. figures like this would suggest that the product is getting more stable, not less.) I use the builds. I feel confortable making judgements based on my formal and ad-hock testing of the builds. I spend a lot of time in the bug database and in the talkback database. I feel comfortable making judgements about stability of the builds. How much time do you spend analyzing bug data, talkback data and testing builds? --Asa > When nearly 200 individual developers set target milestones indicating that they'd like to fix some set of bugs for a particular milestone and don't get 100 percent of them fixed then our project is in jeopardy? Yes, I am saying you should treat any significant shortfalls in bug fixing for milestones as a risk to the project. It presents quite a few risks, actually, but probably the most important one is that it may be concentrating harder bugs into later milestones through a natural selection process by which the easier ones get whacked while later ones get pushed off. This multiplies the risks late in the project, since harder bugs are more likely to be destabilizing to fix. Another problem is that routine shortfall has a negative psychological effect, leading developers to view targets as fluid rather than as commitments. There are other problems, with which a seasoned project manager would already have experience. The rest of the message mostly just says "trust me, I know things are going great." You've been saying that for years now. Even situations which in retrospect you admit were problematic, like the crash landings, you insisted were perfectly all right at the time. You're like the boy who wouldn't cry wolf if his leg was already halfway down the beast's gullet. You've positioned yourself as a cheerleader and that makes it hard to take your "trust me" very seriously. > You can talk about the rising lines and the different curves but you won't convince me that we're not getting better all the time. Everyone acknowledges that the browser is getting better, so this is a straw man argument on your part. The question is not whether it is improving but whether it is improving in a way that will allow a release of reasonable quality within a reasonable time. Because the bug database is not under control, and because the number of outstanding bugs is still large and getting larger, and because the developers don't meet their bug fixing targets, there's no way to know for sure whether it is on track or not, but that confusion in itself suggests a high risk situation. > I've got the mtbf numbers, the user reviews and comments and the direct experience to back that up. I'll take those three things in order. I've discussed with you before why MTBF is a weak quality metric. A system could never crash and yet still be completely unusable -- if you drove the MTBF number to infinity, you could still have a very poor quality product. Crashes are just one class of defect. You never responded to that, and you never responded to my request for links to the MTBF numbers so I could see them for myself. (It later turned out there aren't even any real MTBF numbers for my platform, the Mac, because the talkback program isn't usually installed on that platform.) As for user reviews, they remain very mixed, and I've documented in the past how mixed or negative reviews have been falsely presented as positive here. Your direct experience does not carry a lot of weight with me because of your relentless boosterism, and it also is not a good metric of the stability risk presented by outstanding bugs. That the browser is improving does not mean that it will be of sufficient quality to ship in a successful way any time soon. There are 3560 bugs known to be targeted for releases between now and 1.0. If even one percent of those bugs causes the kind of crash landing that the obscure little bug about submitting non-displayed form elements did, which destabilized nightlies for over a week, then you have thirty-five weeks or more of seriously regressed builds to look forward to. I think one percent is likely to be a very optimistic estimate, since it does seem as if harder bugs may be building up, but even that would mean as much as eight months of extra delay, above and beyond ordinary bug fixing. And yes, this whole time, as a trend, the browser would be improving overall, but it wouldn't be shipping in a form that end users would accept. Now, there are about nine thousand bugs not targeted for 1.0. Some of them have been reviewed, but you keep telling us that a lot of them are junk which hasn't been properly reviewed because you're short-handed. Any of these thousands of unreviewed bugs might turn out to be significant. Any of them might require crash landings. They form a tremendous pool of potential but untracked risk. What's the actual risk there? No one can say. Your experience that the browser is increasing in quality does not really bear on the question of how many of the tracked and untracked bugs will cause this kind of destabilizing impact. Recent experiences and the disturbing "reopened" line, though, suggest that the potential for further problems of this type is very real. Beyond the raw number, one has to look at the line slopes. The open and assigned line is continuing to go up, which means that reviewed and validated bugs are continuing to be reported faster than they're being fixed. That means that at this rate, at the time you expect to be able to ship 1.0, there will actually be more reported bugs than there are now. The risk of crash landings will actually have increased, and you will be looking at shipping a product with many thousands of outstanding bugs. End users will not accept a project that buggy. To get towards a decent quality level, this bug line must go down -- bugs must be fixed faster than they are reported to wind up with a product of reasonable quality. There's no way around it. I don't have any dispute or comment about most of Strauss' reply, but I do want to comment on this one statement: >Now, there are about nine thousand bugs not targeted for 1.0. Some of them have been reviewed, but you keep telling us that a lot of them are junk which hasn't been properly reviewed because you're short-handed. Any of these thousands of unreviewed bugs might turn out to be significant. Any of them might require crash landings. They form a tremendous pool of potential but untracked risk. What's the actual risk there? It appears likely that any really serious issue would be reported multiple times, so that sampling through the bug database will eventually find it even if msny of the reports don't get reviewed. In some sense it doesn't matter as long as the bug gets fixed. ... but with so many unreviewed bugs, how certain can you be that there isn't something in there somewhere (maybe several somethings) that might cause serious destabilization of the code base while it got fixed? Or that it might be missed altogether? Even if it's not something that's a major show stopper for every user, if it has enough impact for enough users (or even a single really important user) then this pool of bugs does represent some degree of unknown risk. >No one can say. That's just it. The risk may be low, but you don't know. --Bruce Hello all, Sorry to jump in the middle of this flame war, but here's my two cents on Strauss' comment that Mozilla is in dangerous downward spiral of instability due to a sharp increase in the number of bugs reported on Bugzilla (my interpretation of his posts, not his direct words). First of all: Strauss, in one of your posts, you not only attacked Mozilla, but also Asa's credibility. You interpreted his post as saying "trust me" and your reply was "I don't trust you." I don't know either of you personally; however, I do think it is important to separate the person from the problem. The problem is that you (Strauss) are concerned about the future of Mozilla, because you feel that Mozilla currently has too many unfixed bugs. In the process of making this point, you have attacked the person "Asa". In my reply I am not going to go into the personal issues related to this topic of conversation. But here is what I think of the bug situation: I use Netscape 6.1 (based on the 0.9.2 Mozilla build) and I find that it is the best browser I have ever used. It is better than Opera. It is better than IE. It is better than any previously released Netscape product. In fact, I am so happy with it, that I have not upgraded to Netscape 6.2. I am currently testing 0.9.6 and I find it to have more quirks than Netscape 6.1. However, this is a milestone build, meant for testing! There will be some quirks. As far as the "usefulness" of Mozilla today: I would say that if Netscape took 0.9.6 today, worked on it for a month, added their propreitary stuff to it and released it as Netscape 6.5, no one would notice. They would praise the tabbed browsing feature and admire the incorporation of print-preview. The remark on its stability. And college students will use it happily. Grannies will send cards through Bluemountain, and people will buy gifts from Amazon with no problems. My point? We have a functional browser here! It works! From the look and feel, from my day to day use of it -I just have to agree with Asa - We have come a long way, baby! Mozilla is in good shape today,and I can say this not with calculated scientific coolness or bland statistics, but with confidence that comes from my gut feeling. In the heart of my heart, I feel this project is on track. I can see the vitality on irc.mozilla.org, I see all of your enthusiasm here. So, let's get over the doomsday predictions, and let's avoid attacking each other's character. For there are bigger and better things to be done, such as building the world's best browser, ever! - Jayesh
I'm not going to address all your points at once because there are a lot of disconnected ramblings here, but to quote you: "I am saying you should treat any significant shortfalls in bug fixing for milestones as a risk to the project. It presents quite a few risks, actually, but probably the most important one is that it may be concentrating harder bugs into later milestones through a natural selection process by which the easier ones get whacked while later ones get pushed off." But I don't see it, with all of the major rewrites landing in the last 4-6 months it is patently obvious that the major problems are being tackled. But once again, unless you can back up your assertion with some semblance of proof it remains a major weak point of your critisms. "I've discussed with you before why MTBF is a weak quality metric. A system could never crash and yet still be completely unusable" You are the one that said "the stability situation is not under control". I responded to that statement with a comment about MTBF. MTBF is the primary measure of _stability_. Usability and stability are two different animals. I never claimed that MTBF was a measure of usability. Don't put words in my mouth. "The open and assigned line is continuing to go up, which means that reviewed and validated bugs are continuing to be reported faster than they're being fixed." That's what happens when you have 16,000+ reporters and only a couple hundred fixers. You'd be more confident about the product if we limited bug reporting to a sufficient degree that fixers could keep up with or outpace reporting? "bugs must be fixed faster than they are reported to wind up with a product of reasonable quality." I disagree. Closing the bug database to everyone but me would have the effect of causing bugs to be fixed faster than they are reported. The product doesn't get better by ignoring problems. If the total number of _known_ defects in a product is 10, you hire 1 million QA engineers to look at the product in more detail and they find 10 more bugs your quality has not been cut in half. If the number of people fixing bugs is steady and the number of people finding and reporting bugs goes up you're likely to see the reporting outpace the fixing, even in an improving product (and especially if you included requests to change or add features). "That the browser is improving does not mean that it will be of sufficient quality to ship in a successful way any time soon." I'd arague that is has already shipped in a successful way, and more than once. Active State's Komodo IDE is a shipping for money release. Netscape 6.1 and 6.2 are shipping releases which users and c|net reviews say it ties IE overall and there are more commercial releases coming. Mozilla has been of sufficient quality for vendors to ship for some time. Netscape 6.1 and 6.2 are proof of that. --Asa Some people have a really hard time seeing this important distintion between the number of reported bugs and the number of actual bugs. You just simply get no concrete indication of the number of actual bugs by looking at the number of reported bugs. It sounds silly, but all the reported numbers tell you is the number of bugs reported. This become insanely important when you have THOUSANDS of reporters which you simply don't have in traditinoal cathedral based closed source products. In order to tell the actualy quality of a project (real bugs) then you need to look at other numbers like MTBF, which you so nicely pointed out. It's amazing how many times this argument has gone over and over here, it shouldn't be this hard for people to understand. Asa, I'm sorry, but this is not a response. It doesn't address any of my points. It just plays word games and puts words in my mouth that I never said, such as my supposed desire to close the bug database, which exists purely in your own mind. I'd like to pull out any points of substance and respond to them, but I can't find any. It's because of messages like this that I can't regard you as a reliable source. That wouldn't matter so much, except that you're saying I should believe things are going well based on your say-so rather than on any kind of actual metric. In another message you finally gave the MTBF link http://ftp.mozilla.org/pub/data/crash-data/ that you've always refused to give me before. I wonder if this has something to do with th efact that the numbers are not very good. I'm seeing reported averages of three to six hours between crashes. If that's an improvement, huzzah, but it's not yet close to where it needs to be for a professional quality product. It should be at least a few days, but weeks would be more in line with how serious products are performing these days. Do you have a graph of the trend there so it would be possible to make a ballpark guess at when MTBF might be more acceptable? Strauss, I'm not a reliable source so don't bother reading any further (and since my comments aren't of any use to you I'll do my best to point my responses to other people). For anyone else that's interested here's a bit more on talkback data. The nightly uptime information is misleading if taken without an understanding of the mechanics and methodology for that data collection. Basically, everytime someone installs a new nightly build it starts the count over so the only stats we get are the people who crash early. People who update builds before a crash happens do not get counted. Also the sample size is very small (nightly downloads are in the thousands where milestone downloads are in the hundreds of thousands) The milestone data is much more reflective of real world usage and the uptime numbers are about 10 times as high as the low figure quoted by strauss. We should have more of this data available soon. (as well as a very cool tool that will let you query for your talkback incidents or incidents with a specific stack signature.) MTBF has been going up steadily for the last year. We're already well ahead of 4.x and our tools for finding and analyzing topcrashers are getting better all the time. --Asa Asa, some of us know you know your stuff. Strauss: It's interesting that you could sit around and bitch about Mozilla on this site for hours upon hours every day, do absolutely nothing constructive for Mozilla (such as verifying fixes, etc.), and drain even the resources Mozilla.org does have by making them come here and defend Mozilla against your uninformed gibberings and your expectations in the stars. Bugs curves are going up because more people are using the product. DUH! And your nonsense about "high-risk" is just a JOKE. What, people are all going to dump Mozilla if 1.0 has outstanding bugs? People will stop using Netscape or Compuserve because Mozilla 1.0 underneath it has bugs in it? Whatever! Even if Mozilla 1.0 isn't perfect - AND WHAT 1.0 PRODUCT IS? - There will be fixes on the long-lived Mozilla 1.0 branch. The point in 1.0 is to freeze the APIs so that people can actually use the product to make applications, themes, etc. The 1.0 branch will be clean, I'm quite sure. I imagine it will go through some serious debugging and I also imagine some bugs will be futured. GET OVER IT. It'd be nice if you had something better to do for Mozilla than try to incite anti-Mozilla riots here at MZ (notably, a site that is PRO-Mozilla. You're as annoying that goon mangelo and Bruce Jensen was before you. I hope you get bored and go away like they did. Maybe you could all form a club! I hope you feel better now. do you think that for example IE is a professional quality product? Than I'm sure that you could explain to me a MTBF of about an hour or so for me....which is another reason why I like to use Mozilla much more because simply it doesn't crash this often. But I'm sure you'll never answer this question... > do you think that for example IE is a professional quality product? Than I'm sure that you could explain to me a MTBF of about an hour or so for me. What's your system configuration? I'm told that on pre-NT-based versions of Windows IE crahsed prety often. I had no problems with it crashing more often than about once a month on Windows 2000, though. On Mac IE does crash more often, sometimes up to once a day, but that actually seems to be Open Transport problems rather than IE proper. (Open Transport was known within Apple as Broken Transport -- there are many known and unfixed crashers within Apple's networking layer, which is clearly the most unstable part of the classic OS.) When on Windows, I'm using Win98SE, I know it's not the most stable system but it works for me (need just ICQ, Mozilla, Winamp, TV, a terminal program for programming and some games). But the point is, that it is even the improved version of a released OS and Version 5 of a released browser so it seems like Microsoft maybe much worse in releasing products of dubious quality... And as you say there are many known and unfixed crashers in this released Apple OS (or this part of it). If professional products are like this and Mozilla is not professional than I certainly like this unprofessionality and especially if it gets better and better like the last time. Well, both Microsoft and Apple have gone a long way toweards cleaning up their act in their newer operating system versions. Unfortunately the IE version for Mac OS X has gotten terrible reviews, which may very well be part of a Microsoft "pollution" strategy meant to slow down adoption of the newer and stronger competitive OS -- Microsoft has sometimes released howlingly bad application versions for Mac, perhaps because it makes Windows look better, but then they'll follow up with something that's actually quite good, like Office 98, perhaps to maintain their lock on the Mac applications market. It's weird and inconsistent behavior and it probably tracks internal political shifts in Microsoft. For quite a while there was a gap between quality levels of the OS and quality levels of the applications, but both the OS makers have made big steps forward in the last year or two. And because the same version of IE that seems unstable on pre-NT-based Windows versions seems rock solid on NT-based versions, I think it's likely that the problems are in the OS rather than IE itself. Do you really have trouble understanding what people write or do you just intentionally misquote and misinterpret all the time? For example, Asa never said that you wanted to close the bug database. He never even comes close to saying that. After all the many times that you try to play word games and put words in the mouths of others, it is extremely annoying to see you falsely accuse someone else of doing it. To Strauss, your argument is completely flawed (lines and bug counts etc.) because you are comparing mozilla with a comercial project with a !!!!fixed!!!!! number of testers. Whereas mozilla has a fluid and continually increasing number of users filing bugs. More people with more time will inevitably mean more bugs filed "Everyone acknowledges that the browser is getting better," "Beyond the raw number, one has to look at the line slopes. The open and assigned line is continuing to go up, which means that reviewed and validated bugs are continuing to be reported faster than they're being fixed. That means that at this rate, at the time you expect to be able to ship 1.0, there will actually be more reported bugs than there are now. The risk of crash landings will actually have increased, and you will be looking at shipping a product with many thousands of outstanding bugs. End users will not accept a project that buggy." First you say that it's undeniable that Mozilla is getting better, then you claim that it will be a buggy mess by 1.0. How do you reconcile these two claims? Even if a bug is left unfixed until 1.0, it doesn't go into hiding and only pop out right then. #161 Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: What happeby bcwright Friday November 23rd, 2001 1:15 PM Asa, I can't speak for Strauss, but what I'd call the "stability situation" (for want of a better term) isn't really how often the product crashes or the like. I think we can all agree that Mozilla crashes a lot less often than it once did, and is a whole lot better than it once was. Rather what is most worrisome is how often lots of new problems get introduced (or old problems get re-introduced), especially when adding new features. Code stability, in other words, rather than how often the product crashes. The issue about what bugs are targetted for what milestone is more of an issue of understanding where you are than it is of whether "enough" bugs are being fixed for each milestone. I would think that the current situation would make your lives more difficult even apart from whether it makes it easier for Mangelo to track his bug counts :-). You even allude to this in your own reply. The other issue is the number of bugs targetted for all releases between now and 1.0. Obviously that will have to be a generally decreasing function of time or you'll never get there except by dumb luck. Until recently this had not been the case. Now I don't know enough about the details of why this is so - how many of these amount to desired enhancements that got added rather than actual errors that were found - but it's clear that for quite a while the situation was somewhat out of control in the sense that these numbers kept going up. After all, the entries targetted for 1.0 (which is supposed to be an actual _release_) matter a lot more than those targetted to just a single _milestone_. My impression is that a lot of them amounted to enhancement ideas that were contributed, which seems to indicate too much of a reluctance to say No. However if most of them were errors instead, then clearly it indicates a situation where either code changes were not being tested and reviewed enough, or where the bug reports were not being reviewed fast enough to figure out which were duplicates and user errors and the like rather than program bugs. Neither situation is good, at least if you ever want to get to an actual 1.0 release. One way or another you have to get a handle on that figure if you're ever going to get to 1.0. Fortunately it's finally been moving in the right direction over about the last month, so there is now some hope that you'll get there. But it's still going to require some discipline and self-restraint. I do think Mozilla has gotten a lot better, I certainly won't dispute that. What I think it needs now is more attention to fixing the remaining "errors" (of whatever description, not just "crashers") and not so much on new "features" - really nothing except extremely low-risk or essential missing features. The tabbed browsing and link features are examples of things that were, in my opinion, very marginal and risky additions at this stage. Not that they aren't nice, but this kind of churning makes it harder to converge; and neither one is essential (they are in neither 4.x nor IE). Things like this can always be added for 1.1. Looking forward hoping for a great 1.0. --Bruce " After all, the entries targetted for 1.0 (which is supposed to be an actual _release_) matter a lot more than those targetted to just a single _milestone_. " The number of bugs targetted at 1.0 is not a realistic measure of the bugs that would prevent a 1.0 from happening but this number should continue to go down as people evaluate them against the kinds of fixes that a long lived 1.0 branch needs. 1.0 is the point at which mozilla says "the code should be good enough for you to use." Things that matter for 1.0 are frozen interfaces, stability (the 'doesn't crash' kind), performance, footprint, etc. (see the manifesto http://www.mozilla.org/roadmap/mozilla-1.0.html for more info). I share your concern that the 1.0 targeted bugs are a lot of 'nice to have' or enhancement bugs and that this can be distracting, misleading and even dangerous. We're working to get that list triaged down to something more meaningful (see the recent drop of about 25%). I also agree with your suggestion that we need more focus on fixing core problems and less on adding features. There are lots of things that can and should wait till 1.1 or later. This will have to happen if we want to fix the api, stability, performance and footprint caatagories of bugs I mentioned above. Bugzilla reports are one method for measuring areas of quality in Mozilla. There are lots of other measures. We test performance, stability, functionality, footprint, etc. You could say that our page layout performance is getting worse because there are more open bugs today reported against performance than there were a year ago but that measure proves to be wrong when you actually look at the page load metrics at news://news.mozilla.org:119/3BFB7296.41831EB9@netscape.com . You could say that our stability (the 'doesn't crash' kind) has gone downhill because there are more open bugs reported against stability (keyword or summary containing 'crash') than there were a year ago but that also proves to be wrong when you look at our MTBF stats over time at http://ftp.mozilla.org/pub/data/crash-data/ You could say that our interface stability story is worse today than it was a year ago because there are more bugzilla reports about freezing interfaces than 1 year ago but the forzen and under review APIs at http://www.mozilla.org/projects/embedding/PublicAPIs.html again demonstrates that a growing number of bugs does not mean we're losing ground. In fact, in many cases, the growing number of bugs has everything to do with gaining ground on an issue. As we focus on something like page load performance and work to drive that metric we test more thouroughly or specifically and report more bugs against code which could impact that metric. For example, if we do profiling on page load and identify 100 pieces of code that could be improved getting us 1% perf increase each and so we file 100 bugs and target them at 1.0 (because page load perf is important to 1.0) and then we only get 50 of them fixed by 1.0 increasing our performance significantly, I don't consider that hypothetical a failure. By the quality tracking discussions I'm reading at mozillazine we should just as well not do the profiling, not find the 100 places we could improve and not work to fix as many of them as possible. It's being suggested here that the only measure we have is the total bug reports and if that number goes up faster than than the fixing then we're getting worse. I dispute that kind of arguement. There are too many places where we have more bugs reported about a catagory of problem today than we did a year ago but that area is significantly better than it was a year ago. --Asa #173 Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Whby bcwright Friday November 23rd, 2001 5:59 PM Asa, I'm not saying that you necessarily need to _fix_ everything that's targetted at 1.0 in order to have a shippable release. Obviously things like minor features or performance-related improvements are optional, I think we all understand that. Nor are bugs that are already targetted at 1.0 likely to be a complete list. Tomorrow someone may find a critical error that had been missed up until now. Obviously that is something that may well need to be fixed for 1.0. All I'm saying is that by some means -- fixing them, triaging them, finding that they are duplicates of bugs already fixed or user errors, or whatever -- you need to get the targetted bug count under control before you can ship a release. Until relatively recently that count had been increasing, not decreasing, and that's not a sustainable situation. One of the famous Russian novelists (Tolstoy?) wrote a short story about the peasant who made a pact with the Devil, that he could have all of the land he could walk around in a day. But the peasant, being greedy, could not resist trying to get every nice parcel he could see into his new allotment. In the process he ran so hard that he killed himself from overexertion. I am concerned that Mozilla is in danger of trying to get every single nice feature or performance tweak into 1.0, and in the process kill itself. Getting out a good release takes discipline, not greed. Best regards, --Bruce "All I'm saying is that by some means -- fixing them, triaging them, finding that they are duplicates of bugs already fixed or user errors, or whatever -- you need to get the targetted bug count under control before you can ship a release." Actually, while it would be nice to see the number of known bugs in the product going down, the number of bugs targeted at a particular milestone isn't going to stop us from having a release, there's nothing stopping us from using a totally different approach than bugzilla for ship criteria. We could create a set of tests and say that when we pass the tests it's 1.0. Those tests could be minimal or extensive. But tests shouldn't be the only criteria just like bug data shouldn't be the only criteria. If all of the bugs in the system were targeted against 0.9.7 that wouldn't stop us from having a 0.9.7 milestone in about 5 weeks. Targeted bugs is useful for getting some idea about what a developer is working on or wants to be working on but it's not our sole release criteria. It seems a little odd that people here keep saying what we can, can't, must do to ship a release. Netscape's shipped two very good releases without meeting all of the criteria set out by folks here at mozillazine. The netscape release http://www.cnet.com/software/0-3227883-8-7614087-7.html?tag=st.sw.3227883-8-7614087-1.txt.3227883-8-7614087-7 http://download.cnet.com/downloads/0-3364665-100-7707040.html?tag=st.dl.10000-103-1.lst-7-1.7707040 has been given great reviews by the press and users. If we were focused on shipping a browser suite we could have already done that but mozilla is more than that. The most important tasks remaining for 1.0 will definitely help the browser suite but are primarily to make mozilla code more useful for application developers interested in making mozilla-based apps or embedding mozilla in other products. #180 Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Reby bcwright Friday November 23rd, 2001 10:30 PM Asa, The usual apology for milestones still having serious issues (not talking about simple bug counts but significant useability issues) is that "a milestone is not a release." I.E., that a milestone is still a beta but a more polished beta than a nightly. You can't have it both ways; I'm afraid that you're playing word games. As for "successful release," well, that depends on whom you ask, of course. I know some people who have promptly removed it from their systems for the sole reason that the MailNews client is so weak even on NS6.2, and gone back to 4.7x. Best regards, --Bruce #192 Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Reby strauss Saturday November 24th, 2001 5:21 PM > As for "successful release," well, that depends on whom you ask, of course. For myself, I would consider a successful release one that got some significant amount of market share back from IE. That doesn't seem to have happened yet. Part of the reason is that IE is firmly entrenched, but another part of the reason is that the quality and performance of Mozilla aren't yet in the zone of what people expect from major applications today. AOL Time Warner may be able to do something about the entrenchment by leveraging their own installed base, but until the quality and performance issues are cleared up, they can't absorb the costs they would get from customer rejection of their preferred browser. #204 Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Reby niner Sunday November 25th, 2001 11:05 AM Maybe the hole discussion is more about what to expect from a 1.0 release. You expect a browser suite that gets user acceptance and a significant market share. Maybe Mozilla.org wants something different? Not that they don't want a significant marketshare, no programmer could resist seeing his program getting spread over the planet but I think they focus more on API stability and usability for application developers than users, this is what I think that asa said before. mozillaquest.com may be crappy but they got a point after 0.9.4 talback seems to be working overtime. Lot of bugs ARE being swept under the carpet. My 0.9.6 just crashed when I clicked an unsubscribe link. I think I will go back 0.9.4 Try clicking on the link again. If it crashes everytime you click on that link, file a bug report. The truth is they don't sweep lots of bugs under the carpet, because they can't be aware of all the possible bugs. Your responsability as an user of a Mozilla milestone is to TEST it and REPORT THE BUGS you find. EXTRACT: Congratulations! You've downloaded a Mozilla build. This means that you've volunteered to become part of the Mozilla testing community. Great! Welcome aboard. Helping out won't take much of your time, doesn't require special skills, and will help improve Mozilla. I see nothing about whining there. Moreover, lots of the bugs are RFE, such as "Mozilla should have <insert feature> like IE". You know, Mangelo and other whiners would be of a big help if they submitted bug reports by the way, and actually told which bugs they're talking about. Instead, Mangelo's just spreading misinformation about Mozilla and resuming the development process to a mere bug count. If this is having a point, then let's all run Amaya. Actually, don't you think the "you've just volunteered" thing is a liiiitle bit coercive? Maybe it should be changed to, hrm, I don't know. Something less coercive. Angelo just takes raw bug counts. I don't see how that's of any help, especially considering most of the bugs are relatively minor. And the "that's too many bugs for a commericial product" is irritating. Firstly, Mozilla *isn't* a commercial product. And secondly, how does he claim what is too many bugs for a commercial product? Especially for a product of this size and complexity. What's Amaya btw? As Mozilla.org always say, they are only providing binaries for testing purposes and for nothing else. I know it's a good browser and many people use it for just browsing and I've no problem with that but they should at least be aware of that and it should be okay to ask everyone who is using Mozilla to write at least a bugreport if he complains about a bug. Isn't Amaya this W3C browser that does the standards correct but is completely unusable for an end user? Have heard of something like that, maybe completely wrong... Hello all, I tried Amaya once and uninstalled it in about an hour. I agree with the post that said Amaya may be very standards compliant but unusable for the end-user. My first impressions of Amaya were not good at all. Maybe it deserves a second look, and maybe my judgements were too hasty. But this brings up another point: that there is a point to all of Mozilla's "features" - i.e. the password manager, good bookmark management, cookie management, the composer, the mail client, and so on. The reason these "features" exist is that they enhance the browsing experience,and make browsing more pleasant. One reason I don't use K-Meleon is that it is too bare, too grey. And hey - I am not using some spiffy, super-fast machine that can afford to run badly written and slow software. So, the "K-Meleon is faster" argument does not work for me. I don't care how fast a browser is if it does not make my life easier. This post is not against K-Meleon; it is meant to show that to make a "useable" browser, you need more than standards compliance and speed. It has to make the browsing experience easier. And if it looks pretty too, well then you've got a Mozilla! - Jayesh
Amaya is a standards-compliant browser-editor being developed by the W3C as a testbed for W3C technologies. It has a few features I'd love to see in Mozilla 2.0: the editing window is the same as the browsing window, so one can just pull up a page, edit it, save it, and reload it all in the same window (the default save method is HTTP PUT), and can open other windows for source and tree views. The document is parsed and stored as a tree, then outputted in (by default) XHTML when saved. It has a working Annotea implementation (Annozilla doesn't work for me), partial SVG support, partial MathML support, good XML support, and partial Unicode support (the only thing that even approaches the quality of Mozilla is the XML support - XML works fine with CSS; haven't looked into XSLT yet, but I don't think they've touched XSLT yet). However, the CSS support is partial, it lacks a quirks mode or SSL (an absolute necessity for a commercial product), it needs a LOT of work on the UI, needs some work on Unicode support, lacks a mail agent, requires Motif or a Motif clone on Unices (it's not available for OS 9 or any other non-Unix, non-Windows OSes that I know of), and pretty much all of the features are Not Ready for Prime Time. However, if you want an easy to use WYSIWYG editor for text oriented or simple CSS pages that will NOT permit you to create an invalid page no matter what you do, Amaya is a good place to start. (Indeed, I think it's best use would be as a tool for teaching someone how to do markup). Comparing Mozilla's quality to Amaya's is insulting to the Mozilla team; there are only 3 or 4 developers working on Amaya, and it shows. The work they've done given their resources is excellent, but Amaya is at best a good midpoint between Lynx and Mozilla with a few 21st-century features. And it's not really intended for end-users, only for use as an editor and, as I said above, a test-bed. The address is http://www.w3.org/Amaya/ BTW, Annotea is a great technology. I'd love to see that integrated into the Mozilla tree after 1.0 branches. And I think the tabbed browsing feature and replaceable toolbars would make a true browser-editor style interface, like Amaya's or AOLPress's, a much more powerful way of browsing and editing (again, AFTER 1.0 is gold). One thing that really needs mentioning, but nobody seems to have done so, is that bug counts *don't* show the number of bugs, they show the number of bugs *counted*. Probably mangelo's biggest mistake is to equate the two. He seems to think that a higher *bug count* means more *bugs* which patently isn't necessarily true. Many people have addressed above the fact that bugs can be counted in different ways, and the single most important thing is that the more people using a product, and the more usable it is the more bugs will be *counted*. If the Linkbar is misaligned by a pixel (as macpeep might quite reasonably enter as a bug into bugzilla - in fact he's encouraged to do so!) that takes up the same number of bugs as if it crashes the browser - it's just that nobody cares about alignment whilst it's still crashing things. There are *loads* of perfectionism bugs in there now - and quite rightly - but these bugs were always there, just uncounted. Same goes for crashes - specific ones get noticed as general ones become more rare - but they were always bugs, just not counted ones. It did not crash the second time. I did not file a bug report since the Talkback app did it for me. I use mozilla as my primary browser and using 0.9.4 and 0.9.5 I never had a crash for something as basic as clicking a link. So now, do you think Mozilla crashes on links ? That would suck, for a browser. My bet is something else than just the link, made the browser crash, but I wouldn't know. Random crashes occur, this isn't a novelty of 0.9.6 "I did not file a bug report since the Talkback app did it for me." but did it? what do you assume to be the function of Talkback? I would appreciate further clarification but as I understand it, Talkback reports are useful in-depth analysis as background reading for a bug report (what was happening as Mozilla broke, not the where and when of the breakage?). perhaps there's documentation somewhere or someone could write it to clarify the differences between Talkback and Bugzilla Talkback reports for the most part aren't analyzed individually (not until that incident is identified as a 'topcrash'). Talkback sends in a stack trace from your crash. The thousands of traces are catagorized and used to identify high occurance crash problems which get labeled as "topcrash" in bugzilla. Talkback is also used to calculate mean time between failure (the 'uptime' of the browser). Bugzilla is used to report specific problems which should be investigated as a unique issue in the product. If you're crashing and talkback catches the crash it is still important to record that as a bug in Bugzilla (include the talkback incident ID). In the next week or so we'll have a webtool available that will let you look up your talkback incident and retrieve the stack trace that is recorded. You can then query for that specific crash signature and see if it is already reported in Bugzilla. If it is reported then there's no need to report it again. In most cases a comment in the existing bug with details about how you encountered the crash is helpful. But if it isn't already reported and you can reproduce the problem then it should be reported. --Asa > I did not file a bug report since the Talkback app did it for me Talkback doesn't file bug reports. It logs stack traces, which can be consulted by devlopers working to fix the crash. But the developer still has to be aware that the crash is occurring, so you still need to file a bug report to get their attention, and attach the talkback ID so they can connect the two. #117 Re: Re: Re: Re: Re: Re: Re: What happened to mozilby joschi Thursday November 22nd, 2001 10:34 AM >I haven't seen such a post. I swear you must have eye troubles, because post's like this one come up every time this stupid thread get's going again. http://mozillazine.org/talkback.html?article=2091&message=114#114 I actually could care less. I hear this guy is a serious goon, and I refuse to lend credibility to morons by adding hits to their sites. I wish people would stop even mentioning that stupid site here. JR Could be posible, we have Only one of each toolbar and one menu on the screen? so if we open a new window, will be faster the display. The Instant messeger window(I use Netscape), work for me like a mainwindow. I have my sidebar(in fact is the sidebar), and the access to the navigator, mail, search, etc. JAVA DOESN T WORK GOOD IN MS WINDOWS. ??? Will all the commands be able to fit in 1 menu? You could collapse the toolbars (click on the bar on the leftmost part of the toolbar) and turn off the component bars etc via view => show/hide I meant one of each toolbar and one menu on the screen for all the windows. The menu and the toolbars out of the windows, fit them to the upside or butttom of the screen, for example. and open many windows we want with only the page displayed inside them ...one of each toolbar and one menu for all the windows If you want a single menu bar, you should get a Mac. You can do this already, simply right click links and select 'Open in new tab' or press CTRL+T to open a new blank tab. There are preferences for these under Navigator > Tabbed Browsing. I don't know what other people have seen, but in the past few weeks I've seen many bugs originally targeted for 0.9.6 or earlier sent off packing to a future milestone or to "Future", and many annoying new regressions. Mozilla is definitely improving, but at this pace, I don't expect to see 1.0 anytime soon. Yes, I\'ve noticed this too. I\'m still using 0.9.4 for the most part. On the other hand, as long as progress is being made I don\'t really care when 1.0 is released. What I\'ve got is stable and does everything I need it to do. Milestones are goals, guidelines, not commitments to fix each and every 0.9.6 flagged bug. 1,600 bugs were fixed in this realease... I think they are well on the path to 1.0. Perhaps you missed the recent story stating that after this milestone focus of QA would be on performance and stability alone? That is, when you say "at this pace" remember that they've already said they're going to change that pace. In my view, this means Mozilla is now almost entirely feature complete as of this release. What you see is pretty much what 1.0 will be, it'll just be a mite (hopefully two or more mites) faster and more stable. What must I do, to give my site an icon, just like Mozillazine (i mean, the little picture in the location bar)? Create an icon, preferable a .png or windows .ico file 32 x 32 pixels (for the .ico you'll need a program that can save .ico; I use Canvas 6 for Windows when I'm on Windows, but that's a pretty pricey program; there are sharewares and perhaps the GIMP does it, too). If it's an .ico file, you can save it as favicon.ico, which is the IE method. Then add <link rel="icon" href="filename.ext" /> to the document head to provide the .png to Mozilla users (you can also use this with .ico files; Mozilla users can also get favicon.ico automatically if they choose to, but the <link> method is preferred). try bitmap to icon: http://www.qtam-computer.com/ it's simple and, um... free :) Not to give any more ideas for "features", but has there been any discussion about saving the icon with a bookmark for a site? I'm pretty sure IE does this - I know when you save a URL as a link (like on the desktop) it uses that site's icon. Then again, maybe I should keep my mouth shut til 1.0 I use Photoshop to crop a picture until it is a square. Then I resize the picture to 16x16 and reduce the color depth to 16 colors. Then I save the graphic as a GIF image. Then I load the file with IrfanView and save it as an Icon file. I think the whole thing can be done with IrfanView but making the picture a square would be difficult. After the icon is produced, I upload it and put <link href="Sexy_Tanyel_Naked.ico" rel="shortcut icon"> between <head> and </head> tags. If the webpage is not in the same folder as the icon then the path has to be included with the filename. The filename should not be the same as mine unless you have the same name and office activities. You must read the 0.9.6 release notes which clearly explain how to do this. Not so clearly, I would say. <LINK REL="icon" HREF="images/mozilla-16.png" TYPE="image/png"> <LINK REL="SHORTCUT ICON" HREF="/images/global/branding/dellecomicon.ico"> Implies that BOTH link elements must be supplied, when they do not. Also, the form is HTML, not XHTML. It should read: "<link rel="icon" href="images/mozilla-16.png" type="image/png" /> or <link rel="icon" href="images/mozilla-16.ico" />" Also, mentioning the fact that "shortcut icon" and "icon" and several other possible values for the relation element will all work is a mistake; better to come up with a standard and keep the support for non-standard formulations out of the documentation as a kind of quirk (not quirks mode, but you get the idea). Also, I'd say that the phrase "shortcut icon" is redundant: an icon is a visual representation of a file or symbolic link or feature, and a shortcut is a visual representation of a symbolic link - "shortcut" is a subset of "icon"; so I'd stick with "icon." Yeah, I know there's a bug with this whole discussion on it. Sorry to be a pain in the ass with these comments, which are merely intended to be constructive; I'm very happy with the support that's been provided (in the recent nightlies; I've stopped downloading the milestones): finally I can tell which tab is which without using my brain! Ignore the above. I hadn't realized that MSIE supported <link rel="shortcut icon" ... />. Went back and reread the bug (bug 32087) and saw why the relnote is written the way it is: because using BOTH links supports both MSIE and Mozilla. Personally, though, I just save it as favicon.ico and add the <link rel="icon" ... /> element. Sorry. This new milestone has settings for Navigtor-->Tabbed Browsing, which is very helpful. Unfortunately, the bottom three settings do not work for me: Open tabs for Windows opened by the webpage - checked it off, clicked on a link with target=xxx and it opens in a new window instead of a new tab. Open tabs for middle-click or control-click of bookmarks and personal toolbar items - doesn't work when checked. Middle-click one of my bookmarks and nothing happens. Control-click on a bookmark and it loads as any other bookmark would. Open tabs for Control+Enter in the URL bar - this feature does work when checked, but it also opens new tabs for a single <enter> in the URL bar. Tried this on two linux machines and yield the same results. Are their manual prefs.js settings for these features I can try? They all would be very nice to have... The missing functionality is covered in bug#110540 http://bugzilla.mozilla.org/show_bug.cgi?id=110540 Just curious; is there any chance that the splash screen will be changed? I'm okay with the screen, but it seems to me that Mozilla could use something a tad bit more professional looking. For myself, I decided to change the splash on my computer to something more suited towards me. I know there was some discussion on this, but it didn't really result in anything. So far it looks good, but I hope the mail client works this time! I'll have to see tonight... The issue of the updated splash screen in bug#32218 http://bugzilla.mozilla.org/show_bug.cgi?id=32218 which is blocked until bug#28028 regarding IP is resolved. I miss the splash screen under Linux, it works fine under Windows. Is there a way to enable it? This little dragon is realy nice, I wouldn't want to change it. The images list feature in View Page Info hasn't worked for me since 0.9.4. I get a list of the images but when I ckick one, it appears in the bottom frame for a split second and then disappears. Anyone else having this problem ? Page info is getting a major rewrite at the moment and that problem is fixed in the new page info. #42 Re: Re: View Page Info -> Images does not workby fuzzygorilla Wednesday November 21st, 2001 9:28 AM I think the bug covering the rewrite is #52730 http://bugzilla.mozilla.org/show_bug.cgi?id=52730 http://www.zdnet.com/zdnn/stories/news/0,4586,2826611,00.html I like the quote "...many users have grown tired of waiting for the project to reach a conclusion". Er, what conclusion ? The only "conclusion" (apart from the fact that ZDNet UK are clueless) to Mozilla would be if mozilla.org, Netscape, AOL and the open source community all abandoned it, which is highly unlikely to happen. Maybe "...to reach a 1.0 release" might have been more accurate, but even that is a bit dubious since development will continue apace even after 1.0 comes out. Is it just me or does it look like the guy who wrote this never actually downloaded and ran Mozilla 0.9.6? Looks suspicously like he just paraphrased the release notes to me. This new milestone has settings for Navigtor-->Tabbed Browsing, which is very helpful. Unfortunately, the bottom three settings do not work for me: Open tabs for Windows opened by the webpage - checked it off, clicked on a link with target=xxx and it opens in a new window instead of a new tab. Open tabs for middle-click or control-click of bookmarks and personal toolbar items - doesn't work when checked. Middle-click one of my bookmarks and nothing happens. Control-click on a bookmark and it loads as any other bookmark would. Open tabs for Control+Enter in the URL bar - this feature does work when checked, but it also opens new tabs for a single <enter> in the URL bar. Tried this on two linux machines and yield the same results. Are their manual prefs.js settings for these features I can try? They all would be very nice to have... Any workarounds for getting the Modern American theme working in .9.6? I just discovered this theme and it ROCKS. I guarantee I can get 10+ people to load Mozilla when they see it. (I work for the government.) Just out of curiousity, would it be easier to get everyone else to use Netscape 6.2? It's essentially the same except for all the things inbetween .9.4.1 and .9.6 =] Hmmmm... In going to 0.96 from 0.94 I find that the font size has shrunk at a number of sites (e.g. space.com, theregister.co.uk). Is this a bug or a feature? (At my age I prefer the previous larger fonts...) You're right, the fonts are often smaller know. It was already in 0.9.5. But I don't know if we should consider it a bug or not. There is a handy keyboard shortcut for that sort of problem: Ctrl-+ Just try it, it will increase the fontsize. Use Ctrl-- to decrease it again. Same as View -> Text Zoom -> Larger When I use the numeric pad only - works but + gives me nothing. Only the + on the main keypad works. This is on a german keyboard, Win98. Hmmmm... In going to 0.96 from 0.94 I find that the font size has shrunk at a number of sites (e.g. space.com, theregister.co.uk). Is this a bug or a feature? (At my age I prefer the previous larger fonts...) Does anyone know where I can find the Sullivan package? It was a UI overhaul for Moz that gave it a more Mac like apperance and game in a few "flavors". Is it still around and being worked on? Does it work with 0.9.6? I'm just trying Moz again after a while, it's come a long way but I dislike the blueish modern, Grey Modern isn't updated and Classic is bland looking. Thanks for any info. It is part of Aphrodite, which is a whole browser update, and apparently was orphaned. Go to http://www.mozdev.org/ and search for "Aphrodite." I liked Sullivan too, but the folks working on it got swallowed up in a buyout at the height of the dot com craze and for one reason or another Aphrodite has lain fallow almost since then. #51 Like the no default page when openning new windowby davemozine Wednesday November 21st, 2001 12:05 PM Openning *no* page when I run open a new window may seem like a minor improvement; but, I think it is an incredable usability boost. Great decision, whoever made it! #62 Re: Like the no default page when openning new winby morg Wednesday November 21st, 2001 2:37 PM What do you mean? #76 Like the no default page when openning new windowby davemozine Wednesday November 21st, 2001 5:54 PM Whoops.. I just realized that this is an option in the navigator preferences. Apparently, when I upgraded, the default switched to blank. Boy, I am a dufous. Anyway, I still like this new preference. Just, the whole world doesn't need to know. #90 Re: Like the no default page when openning new windowby thelem Thursday November 22nd, 2001 2:05 AM This is not a new preference, it has been there for ages (certainly before 0.6, it probably came in about M5 time). Could somebody tell me if this feature exists in IE? If I am visiting a page using IE and use CTRL+N for opening a new window, the new window will start rendering the same page as the old window. This can take quite a while and is terribly annoying. I know that I can press ESC quickly after CTRL+N, but I would prefer that CTRL+N just opened an empty window. Please don't make this into a discussion about whether or not I should use IE :-) Being a web developer I use a number of different browsers. It does. Go to the Internet Options dialog (In IE6, it's Tools > Internet Options), and in the Home Page section, click on the Use Blank button. Still heavy on the memory. I started it and it was using 39,000K and in less than 20 minutes it\\\'s up to 43,000K. (Windows 2000 (SP2) PC AMD Athlon 700 with 768MB RAM) Maybe this is just the memory cache filling up? Normally it's at 4MB (although Mozilla is much faster if you can give it some more) The start up value is high for sure. But the increase of 4mb in 20 minutes is reasonable as that is likely what your ram cache is set to if you haven't altered it. Opera has a cool "Automatic ram cache" feature (well, if your not on Win 9x at any rate, I think the current beta currently causes all your resources to be nobbled). Opera's caching is clearly more aggressive than Mozilla's, but in the case where you're lucky enough to have a large amount of memory there's no reason why a browser shouldn't use it for cacheing if there aren't any other demands on it. What I'm basically trying to say is that using a lot of memory isn't intrinsically bad. If you are using it for good effect and not taking it from other applications then it's a good thing. Mozilla isn't quite there though I think.... Is anyone else finding any peculiarities with the password manager in 0.96? When I posted my last message here I was asked if I wanted mozilla to remember my password etc. for this site and I chose to do so. Now whenever I view this page mozilla gives me a pop-up which contains the _titles_ of my previous messages here and says "Select a username to be entered on this form". This is annoying as well as useless! Password saving just does not work on Mozillazine talkback forums. This is just because Mozilla takes the first textfield in a form as username if theres a password field. If they'd put the loginfield just above the titlefield there would be no problem and Mozillazine would not stay the only site where password saving does not work for me ;) Could the feild stored by the password manager be chosen by the user. I could then select the login field on Mozillazine to store the password by and this problem would (?) be solved. As it is designed the password manager is useless and might be so annoying some users will select another default browser. #197 Solution for Password Manager peculiarity in Mozby JayeshSh Sunday November 25th, 2001 3:20 AM Hello, Here is a quick and painless solution to this "problem." If you already have multiple entries for Mozillazine in your password manager, go to (the) Tasks (menu) - Privacy & Security - Password Manager - View Stored Passwords. Delete all but two Mozillazine password entries: leave one Mozillazine post-entry (any one with an "Re:blahblah" is fine) and leave the original Mozillazine registration entry there (if you saved your password when you registered with Mozillazine, you will see your Mozillazine username in this entry.) Then, the next time you try to post a reply to a Mozillazine message, your password will be automatically filled in. And after you go through these steps, make sure to click "no" in the future when you are asked if you want to save your Mozillazine password on another post you make. Hope this helps. - Jayesh PS: I don't think the Password manager is "useless"; even if you have multiple entries for Mozillazine - you can choose from them and the right password will be entered, regardless of which one you choose.
IMHO the oassword manager still has this major bug for such forums such as Mozillazine. The password manager should have a preference such as "do not request another password for Mozillazine.org" (or whatever site you are at. If not you might accidently add more than one password and have to go through a complex fix (especially for Netscape 6 users). If I want more than one screen name at a given forum, listing the password by the title of the post makes this feature useless. Here is a summary of how the password manager might be st up to function more efficiently: When you enter a password: 1. A dialogue window pops up with the following preferences/choices a. A listing of all the fields being stored. b. An option to select one of the fields as the field to store the password under. (I could choose the screen name insted of the title of the posting) c. A check box to select "Don't pop-up the password manager unless a new value is entered in the field selected in "b.". d. An option to select one profile, if the user has more than one, for the entire session. (Now if a user wants more than one screen name for a forum, the password manager pops up for every post.) c. The ability to edit the values the password manager stores, both before and after it is stored. For many users the password manager, may not be completely useless, but lacks much of the functions for it to be a useful tool. For many users of Netscape 6 (and even Mozilla) may become so annoyed with the way the password manager now functions at Mozillazine and other like forums that they either will not use the password manager or quit using Netscape/Mozilla. We want to encourage users to adopt Netscape. The way the password manager functions on forums could cause many users to select another browser. (One were a password manager is not poping up as each posting is read.) For me this is a "bug" in the loose sense of "bug". It needs fixing. It may not be easy to fix, butunless this bug is looked at, leaving the P. Manager as it is could mean that some users will give up using Mozilla. Mozillazine is the only site where password manager doesn't really work for me. And there is still the button for never asking to save a password on this site. It's not perfect since you have to type in your password manually but this is just for a few sites and the majority works. But it's true that password manager could be a bit more intelligent but I think there are already bugs filed to improve it. Is anyone else finding any peculiarities with the password manager in 0.96? When I posted my last message here I was asked if I wanted mozilla to remember my password etc. for this site and I chose to do so. Now whenever I view this page mozilla gives me a pop-up which contains the _titles_ of my previous messages here and says "Select a username to be entered on this form". This is annoying as well as useless! That's an old bug. I think it is related to the choice of text box names: perhaps if "Title" wasn't called "Title" it wouldn't happen. I select "Never for this site" for Mozillazine.org and that fixes the problem. Why can't mozillazine.org just fix this then, it seems stupid that a site for mozilla advocacy knowingly doesn't work properly with Mozilla's password manager. Actually, it looks like there's a better explanation than mine above. As for why Mozillazine can't fix it, well, would you rather that Mozillazine people who also volunteer on Mozilla fix Mozillazine or Mozilla? I'm guessing that would be your answer (I am affiliated with neither, I just report bugs). If someone can give me access to the Mozillazine site or their talkback forum I could fix that. Thanks for the offer but I think we need to take a look at the bigger picture. A fix for Mozillazine would stop the Mozilla password manager bug from rearing its head and would not solve the bug. There are a couple of chat sites I visit were the password manager cannot be used as it files the password under the post title of the post rather than the user. Fortunately most of these sites supply a cookie, but for security reasons I would much rather use the password manager. I would leave Mozillazine as is, showing the bug. It is a reminder that the password manager does not function well with all sites. When a programer has some free time or is already dealing with the password manager code for another reason, this bug may be dealt with. I would rather have the password manager fixed to work at more sites rather than re-write the Mozillazine site to bury this bug (and by hiding it it may be forgotten and never fixed.) I really would like this bug fixed not swept under the carpet. I understand it may take until after version 1 and maybe not even until v1.5. The Mozilla programers are doing amazing work but they cannot be expected to deal with every bug that "bugs" us/me the most. I cannot deamnd that my top 10 list of bugs to be fixed as soon as I demand it. If I could program in any other language besides Fortran, then I might look into the issue, but I can only report bugs. Dave532, If you don't have patience, how will you be a doctor? (I don't know if that was funny, or not. If not, I apologize in advance.) My point here is: why use words such as "stupid"? The spirit of Mozilla seems to be "If you find something broken, go ahead and fix it." It is okay to report a bug/problem/frustration with Mozilla. However, adding adjectives such as stupid serves no purpose other than working people up. There are plenty of annoyances with 0.9.6, and there is already a flame war going on in other posts (sparked by Strauss' relentless criticism and personal attacks.) Let's keep Mozillazine peaceful, friendly, and open to all. Regards, - Jayesh
Just downloaded Moz 0.9.6 and I notice that it is very sluggish when entering text in "compose" in hotmail. In fact same prob seems to be occuring on this form. There seems to be almost a second delay from when a char is typed on the keyboard to when it is displayed on the keyboard. Can easily type a sentence or two ahead at avg speed (40 or 50wpm). Win98SE, 350MHz, 384MB, lots of GB of diskspace avail. Downloaded and installed JRE 1.3.1_01 from Sun. First time downloading Moz on this machine (which has NS 4.76+IE 5.01). Hello, I was having the same problem as Saidiadude on the Mozillazine site. When I reach the end of the "Response" field, the text blinks or 'shivers' when I try to continue typing. Here is a workaround I have found: Press the enter key several times (to create blank lines) when you reach the end of the form field in your Hotmail message. Repeat this process again when you reach the end of the text field. I do not know if this is an established bug or not. This bug seems to occur after a certain number of lines in a form field. If anyone else has information on this bug, that would be greatly appreciated. (It is somewhat hard to reproduce - for example when I was typing this reply, it twitched for some time, but then stopped. Weird - I have not figured this out.) Regards, - Jayesh Some guys are doing a project to make Mozilla a better porn browser. http://mywebpage.netscape.com/aufbau01/ I cant get mozilla running under any other users other that root. If I install it under root, it works great, but only when logged in under root. If I install it under another user, it works fine first time it loads just after finished installing, but next time and the subsequently, it hangs my system to the point where I need to reboot (reset). It may well just be me, but it sure is annoying. Damien Just to ask the obvious: Did you follow the installation instructions in the release notes? I have since got it working. Yes the install intructions say not to install as root, but when I tried to install as another user it wouldnt, so I had to install as root. I have since figured out the problem (permisions in home directory) and now can install as any user, so my problem is solved. Thanks. Just wondering, but I upgraded Mozilla via Debian's apt-get and the version in the title bar is 0.9.5 still. Was this just a slight oversight, a mistake in the Debian package, or just some weird bug? In the Help|About Mozilla, it does show 0.9.6. I did upgrade from 0.9.5 and deleted my ".mozilla" directory to start from scratch. Other than that, it's been pretty good. It feels faster at least, and that's always a good sign. =) The question crept up earlier: why not convince people to use ns6 instead of mozilla? yes, why indeed? can anyone give me reasons? From www.mozilla.org/releases, "We make binary versions of of Mozilla available for testing purposes only!. We provide no end user support." Notice how the first time Mozilla launches, it directs you to a page about volunteering? I assume most users just want to use a browser, and not testing for Mozilla. In that case, Netscape 6 is a better-suited product. It is a recognized brand name (something that the corporate world concerns greatly), and it is geared toward end-users. You may argue that Mozilla has more features and is purely open-source. But remember that many features in Mozilla builds are only in testing stage and certainly not mature enough for general use (e.g. the link toolbar and tab browsing don't work properly with each other in 0.9.5). And unless the person you're trying to convince is an open-source advocate, he couldn't care less about how Mozilla is free from commercialism. The way I see it, if more people use Netscape 6, Mozilla users would also benefit. After all, the Gecko rendering engine is all about standard compliance. Recommend the right product to the right people. #233 Netscape's Magic -(recommend Mozilla or Netscape?)by JayeshSh Monday November 26th, 2001 3:17 PM Hello all, I agree with sleepy that people interested in the principles of open source would love to hear about Mozilla, whereas the "average Joe"/ your Granny would probably find Netscape easier to use. I think Netscape has really shown the extent of its magic with its 6.1 and 6.2 releases. I use 6.1 as my main browser, and it feels as complete and polished as an "professional" browser should: from the start up splash screen, to the incredibly elegant AIM in the sidebar, Netscape 6.1 proves what sorcery Netscape is capable of: it has managed to tame the dragon, while not stealing its fire! What I mean is: By working from the already solid work of Mozilla (which may be considered rough around the edges by some) Netscape has released an impressive and professional browser - not only validating the existence of Mozilla, but also providing new hope for those Netizens who do not want to put the fate of their Internet browsing experience in the hands of one company alone. (Say, which company could that be? ;-) ) I am really waiting to see how the world will react to Netscape's release of Mozilla 1.0. Cnet's News.com editors will finally have to overcome their pro-MS bias, and many many users will be convinced of how good a Mozilla browser can be. Regards, - Jayesh Mozilla and Netscape 6.x are not competitive applications. NS 6 is based on Mozilla code (added some proprietary extensions, plugins and ui fixes). What you see on a new "release" of Mozilla is at least two months ahead of the latest NS6.x release. Mozilla binaries are released mainly for testing purposes. From time to time (when trunk stabilizes, especially but not only on milestone releases) it is quite usable for simple users. Although the lack of plugins, separate icons, spellchecker etc might repulse the average user from using it. Personally I prefer it over NS6, both at work and home. Thanks for your answers, but I couldnt see a single argument for NS: mozilla "releases" seem to be as stable as NS releases, are much simpler to download and install, are available for more systems, are availble for solaris w/o the need to go to sun and register, dont have unnecessary stuff added and have more features. NS on the other hand, is branded -- so what? Don't do it! Here's some actual reasons: - Netscape releases have a *hell* of a lot more testing. NS6.2 was based on 0.9.4. It ended up coming out around the same time as 0.9.5. That means that 0.9.4.1 (the final open-source version of NS6.2 had *twice* the QA and bugfixing than your average Mozilla release. During that time, a lot of stability fixes are made. - NS6 comes with a lot of fluff that, believe it or not, peole actually like and use. Real, Winamp, AIM, etc, etc. - User support. Netscape provides help and tech support if people need it. NS6's online help may actually be useful, as well. - Corporate support. Companies will be releasing products and making web sites that work with NS6, not Mozilla. - No scary and confusing things like the Debug and QA menus, Javascript debuggers called "Venkman", something called "chofmann's browser buster". - A *lot* of polish. Polish, polish, polish. Again, actual users appreciate this stuff. So, the moral of the story is use Moz yourself, but give Mum and Dad NS6.2. I am using the mailer since Mozilla 0.9.1 or so and with great pleasure (although somewhat slow). In 0.9.6. I really like the search-field just above the listing of the mail to quickly search the current mail folder. However, I very much dislike the way the header of the mail is displayed. It is either too short (just subject and from-field) or much too long. I really really prefer the old way of displaying the mail headers as exists in 0.9.5 and before. Please please return to that view as soon as possible (but keep the search field above the listing). Have you tried selecting the: View > Headers > Normal menu item in the mail window? The way headers are displayed in mozilla just sucks: either you have to give up a lot of space to see them all or you get a truncated subject line for the concise display (who had this idiotic idea of showing subject line and address side by side anyway? I have long subjects already truncated in the message list pane, so I want at least see it in the actual mail window!) I wish there would be at least a preference to have it displayed 4.x syle: just incorporate everything into the scrollable window. If the header has to be in its own pane it should be possible to set the (max) size of the pane and make it scrollable for those of us who want full headers, or let users customize what and how to show. Coming from 4.x mailnews is a pain and a frustrating experience. What's the difference? Favicons are a Microsoft proprietary creation; the name relates to IE Favorites. Favicons are also typically requested by IE whether or not they exist for a site. Site icons are more generalized and open standards oriented; Mozilla will use them in the url window, bookmarks, links toolbar, and possibly desktop icons for a particular site. These site icons are typically only requested by Mozilla if the web designer specifies that they exist by using a LINK tag. Site icons do not have to be named favicon.ico and they do not even have to be .ico files. Mozilla also has some support for favicons, but it is currently defaulting to off because of a debate about whether or not it is ok to have the browser requesting a favicon.ico file which is frequently nonexistant. The implementation of favicons.ico is also not according to any standards spec and so there is some debate about whether or not we should support it based on it being a non-standard. IE also has some some support for site icons via the LINK tag. However there is some debate about whether IE supports it properly. The W3C specs relating to site icons are not 100% clear, so it is unlikely that the debates will stop until they say something more directly addressing the issue, but until then Mozilla is trying to support them in the most standards friendly and non-proprietary way as possible. well I did a quick check whether the siteicon link tag works and couldnt get it to work with a recent nightly --- however konqueror does show the icon. on the other hand i see many sites with an icon in the url bar and looking at the html source, there is no link tag ... so it must be a favicon not a site icon? and is there a difference between the two different rel- values for the link tag or are they just synonyms? The tag you need is <link rel="shortcut icon" href="myicon.ico"> or <link rel="icon" href="myicon.ico"> Depending on the version of Mozilla you are running, favicon.ico from the root directory will sometimes be fetched automatically. This is controllable via a hidden pref which (I very much hope) will be defaulted to off once the feature has had sufficient testing. Mozilla.org needs to get a clear policy on this (preferably together with the W3C) so that people know what to tell website owners. Subj... Tnx! Ctrl + Pg Down or Pg Up It seems 0.9.6 cannot forward more than one Mail at a time,especially HTML Mail, as attachments?? I usually report my spam via spamcop.net, and today when I sent off the usual daily complaint with 8 attached messages, only one item appeared in the Attachment pane of the Compose window. Upon inspecting the resulting message in the "Sent" folder, nothing was actually attached. Very bad! Could someone who uses dailies maybe check this? I'm no master of bugzilla, but this is *very* annoying. I assume you are using the "Forward As" option to forward multiple messages as attachments. If you are seeing this problem in 0.9.6, I would recommend opening a new bug in bugzilla http://bugzilla.mozilla.org/enter_bug.cgi . Alternatively, you may want to re-open bug#107660 http://bugzilla.mozilla.org/show_bug.cgi?id=107660 . #107660 was checked in on Nov-02 and 0.9.6 was branched on Nov-09 so it should be included in 0.9.6. If you are trying to automatically forward each message as a separate message in a single operation, then this feature does not exist yet in Mozilla http://bugzilla.mozilla.org/show_bug.cgi?id=84131 . Where can I get a list of all keyboard shortcuts for Moz Well, here the simple mozilla skin for 0.9.6. themes.org still be frozen and this skin's validity is decreasing day by day toward 0.9.7... http://gashu.org/mozilla Why not post in on http://www.themes.org/? Tis a little bare now. Themes.org doesn't seem to be frozen anymore... Still waiting for them to fix a bug with the installer script, notice that the installation for the existing mozilla themes on the site doesn't work :/ feedback@themes.org if you want to tell them that getting mozilla working is a top priority. Thanks fro doing this, i really missed having a small toolbar :) Or try my themes at: www.geocities.com/alfredkayser/mozilla/themes.htm They are all updated (or newly created) for 0.9.6. The web site you are trying to access has exceeded its allocated data transfer. Visit our help area for more information. Access to this site will be restored within an hour. Please try again later. http://www.geocities.com/alfredkayser/mozilla/themes.htm Move to tripod! :) Littlemozilla's improved since I last saw it, and text labels are gone (kinda defeated the theme's purpose actually). Star Trek is... interesting. A bit garish for me, but bright and visible (both in colour and size of objects). Maybe a more conservatively coloured version? You *could* keep up with the latest XUL changes, but that'd probably be bothersome. Are there any XUL changes coming up? I tried 0.9.6 because I still use Netscape 4.79 for my mail client (in Windows 2000), and I want a better browser, with a similar mail client. Unfortunately, after using 0.9.6 for 1/2 day, I've determined that the mail client has too many bugs, and I also hate the sidebar folder list. I love the drop down folder list in 4.79, it doesn't take any horizontal space away from my message list and message text boxes. Also, in the short time I used it, the browser has crashed on two different web sites, for which I submitted feedback. And when playing a Java game, it's slower and the sound is worse than on 4.79 (or IE 5.5 for that matter.) I wish development had continued on Netscape 4.x, because it was once a great browser with a great mail client. And up until recently, I've encouraged many people to use Netscape instead of IE. If I could find another nice mail client (I've used, and dislike Outlook, not to mention the Outlook security problems), I'd switch to IE, because I am tired of waiting for a better "Netscape" (and I have been waiting and waiting and waiting . . .), and the occasional times I use IE 5.5, I find it faster and, on many sites, more functional than 4.79. So, can anyone recommend a good mail client (and a good newsreader) for someone who really likes the Netscape 4.79 mail client, and who wants to switch to IE instead of waiting for a better "Netscape"? - Eric, http://www.InvisibleRobot.com/ "the mail client has too many bugs" thats something people appear to have massively re-focused their efforts upon, see this MozillaZine description: http://mozillazine.org/articles/article2079.html and this document: http://www.mozilla.org/mailnews/current/performance.html for details "I wish development had continued on Netscape 4.x" it did. work continued, in an Open manner, under the name 'mozilla.org', to develop version 5, which was scrapped and the numbering moved to version 6, or 1.0, depending how you look at it. "because it was once a great browser with a great mail client" and you'll notice by the numbering (0.9.6) that it isn't yet in a finished state, and that you're getting to try it before you would otherwise have been able to if it were in closed development. the fabled finished state is now within sight, so if you wait, Mozilla will likely be that "great browser with a great mail client" "If I could find another nice mail client" in my opinion, no email problem has ever come close to Pegasus Mail for Windows by David Harris. you can find (version 4.01) here: http://www.pmail.com/ I have Pegasus 3.12c. I used it's "Selective Mail Download" to clean out my POP3 mailbox back when I was downloading mail onto two different computers (both running Netscape for e-mail). Other than that feature, which I currently don't need, I don't like it at all. I really hate the multiple windows inside a larger window idea, and when I send a message, there is no way I could find to tell it automatically to put the sent messages into a folder, but I could set it to ask me every time, which is rediculous, because I always save my sent mail. In fact, I prefer Outlook over Pegasus 3.12c, and I don't like Outlook. Is Pegasus v4 that much better than 3.12c to make it worth using? - Eric, My Web Page: InvisibleRobot.com http://www.InvisibleRobot.com/ #156 Re: Re: Re: 0.9.6 mail bugs and browser crashesby thegoldenear Friday November 23rd, 2001 10:59 AM "and when I send a message, there is no way I could find to tell it automatically to put the sent messages into a folder, but I could set it to ask me every time, which is rediculous, because I always save my sent mail" I feel us getting hideously off topic, but I do have to say, I think you're trolling, surely, because in version 3.12c you have this clutch of preferences to help you achieve just what you claim to be wanting to do: Tools -> Options -> Message Settings - Copy to self : on/off (this acts as a default setting for all messages sent) - Ask whether or not to make a copy to self : on/off (this allows you to choose whether or not to be prompted) - If making a copy to self, ask which folder to put it in : on/off #157 Re: Re: Re: Re: 0.9.6 mail bugs and browser crashesby ecarlson Friday November 23rd, 2001 11:38 AM > Tools -> Options -> Message Settings - Copy to self : on/off Thanks. I see it now. I don't know how I missed that. I looked through the options at least 5 times, but missed it every time, and couldn't find any instructions in the HELP file. - Eric, My web site: InvisibleRobot.com http://www.InvisibleRobot.com/ > "I wish development had continued on Netscape 4.x" it did. > work continued, in an Open manner, under the name 'mozilla.org', > to develop version 5, which was scrapped . . . Yes, very sad. > you'll notice by the numbering (0.9.6) that it isn't yet > in a finished state, and that you're getting to try it before > you would otherwise have been able to if it were in closed > development. the fabled finished state is now within sight, > so if you wait . . . That's exactly what I was thinking this time last year, when I figured it would be out by late this year, now I've given up waiting. I think people are dreaming if they think it will be out of Beta in only 4 more months. And I think it's rediculous the simple things that don't work in 0.9.6, like every other time I change preferences, and try to click "OK" to save the changes, nothing happens, and I have to exit preferences and select them again. Simple things like this should have been working fine a year ago. - Eric, My web page: InvisibleRobot.com http://www.InvisibleRobot.com/ I have tried a couple of mail clients in the past and am now using Mozilla for allmost a year. I first used Pegasus, which is great, but it's a real hassle if you have more than one mailbox and it didn't support HTML too well. I do see there's a new version now, that should support HTML better... I also used StarOffice for a while. The biggest problem with this software is that if you file mail into different folders, they are stored like normal files and a lot of header information is lost or hard to search for, making storing mail outside your inbox not really an option. I'm now using Mozilla for allmost a year and even one year ago I thought Mozilla was the best free mailclient (and a lot has changed and been impoved since), especialy if you have multiple mailboxes. I upgraded to 0.9.6 yesterday (I was using a recent nightly build before that) and my browser has since crashed about two times, while the nightly build hadn't crashed for quite a while. Maybe this is accidental (the milestone should be more stable than the nightly build, I would think...), or maybe you should come back within a couple of days and give a nightly build a try. Don't try the one that's in the build bar right now (11/20/2001), since it has a bug that makes it impossible to file mail in other folders within the mailclient... Give Mozilla a second chance! It's not perfect, but it does happen to be the best (I think). - Bart "but it's a real hassle if you have more than one mailbox". by "mailbox" do you mean the place to store your mail on disk, or POP3/etc account? I use a few mail accounts with Pegasus and find it very straightforward "it didn't support HTML too well". rendering HTML has been given a lot of attention in the new version. to quote the web site: "Pegasus Mail can now display practically all HTML content, and can compose HTML messages containing tables, graphics, hyperlinks and more". why bother putting the work in to creaing a rendreing engine when there's Gecko tho? (not that I want to dissuade people from using Mozilla, as then you can take your email application with you as you change operating system. but Pegasus is worthy of consideration as it does so much more than most other email clients) I did indeed meant to say "POP3 account". When I used Pegasus (this is a while ago, but it was version 3.??, if I'm not mistaking), you had to switch users everytime you wanted to check an other mailbox. So you couldn't really set it to check multiple mailboxes in one go. I do seem to remember (it's a long time since I last used Pegasus) that it became possible at a certain time to have multiple accounts within one Pegasus-user (at which point I had allready created all those users to check my different POP3 accounts), but all mail arrived into one inbox. I didn't really get round to trying this. If you're computer is memory-challenged, I would certainly recommend Pegasus. For all those new computers with lots of memory, I think Mozilla is the best (free) mailclient. THE VELOCITY CAN BE A FEATURE OF THE PRODUCT, WHY IT HAS TO BE "SUPERFASTER"? WHAT IF I JUST WANT NAVIGATE IN INTERNET AND NOT HISTERICALLY RUN BY IT? Is there a way to see which bugs have the most votes on Bugzilla? Thanks. Go to the bugzilla query page http://bugzilla.mozilla.org/query.cgi and enter your threshold for the vote count in the "At least __ votes" field. After the list appears click on underlined "Votes" column header to resort the list based on the number of votes for the bugs. Example ("At least 25 votes"): 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=25&chfieldfrom=&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=&keywords_type=anywords&field0-0-0=noop&type0-0-0=noop&value0-0-0=&order=bugs.votes%20desc%2C%20bugs.priority%2C%20bugs.bug_severity My father downloaded 6.2 on my parents' iMac, but my mother refuses to let go of 6.1 mainly because she doesn't like the lines that 6.2 draws to show the hierarchy of folders in the Mail folder pane. Is there any way to turn these lines off? I'm impressed that they got print preview so early, considering it was origonally planned for 1.01, well done! ...But how do you go from preview mode back to normal view??? Print preview is kind of incomplete. It only shows 1 page on framed pages. You don't have the ability just to print one frame. The switching between normal & print preview doesn't work (in spite of what some say). I am guessing 1.0 is when it will be feature complete. hit the back button When will Mozilla support the history in the fields? I am ODP editor and when I try to write a new URL in the Add New Site field Internet Explorer show the history with the previoos URLs. Unfortunately it is not the same with Mozilla. I think what you're asking for is http://bugzilla.mozilla.org/show_bug.cgi?id=60861 . If I'm correct, please vote for that bug :) PS what's your username on dmoz? I'm jesser. "The file /C:/Program%20Files/Mozilla/chrome/packages/aim/SidebarPanel.xul cannot be found. Please check the location and try again." I got this error in 0.9.5, and it is still here in 0.9.6. Overlayinfo is the only directory I have under chrome. My newsgroups use to stay expanded when I started Mail, which is how I like them. Now when I start Mail, I have to click on the server to expand it back out, every time. Brings to mind a comment made awhile back about 2 steps forward, 1 step back. I have noticed several instances of saving web pages to disk, then opening them up in an editor and seeing crap instead of HTML. When I download that same page in 4.78, then open it up in the same editor, I see HTML. Does 0.9.6 do something different? It worked fine before. Sounds like conflicts with a 6.x profile. Try a fresh profile, and copy over the mail files manually today i wanted to read this nice site and i got this error (can't select from the database) and later i got (when i clicked on an article ) that again guys what is the database back end of this site coze i want to help u if u have problems . some ideas is to put the database on an separate computer (solution like on ./) and then write all the selects in the stored procedures (inside the database) or do some distributed (2 computers with 2 replicated databases)stuff this happens quite often on this site. Seems like the user limits of the database are too low? There were never speed problems so I think the machine can do more users and it's just a problem with the configuration. But I don't know anything about how the site is run so maybe I'm totally wrong ;) Hello all, I recently upgraded to Homesite 5, and discovered this much unpublicized feature: Homesite's (supposed) capability to use NGLayout/Gecko/The Mozilla rendering engine in preview mode. The help section was a little unhelpful. Here's a quote: -- * -- If you have Netscape version 6 or later on your system and you correctly install and configure the Mozilla browser NGLayout/gecko control, you can use Netscape as the internal browser. Please note the Mozilla control is under development and is limited in its functionality and stability. For setup instructions, see "To install and configure Mozilla:". [...] To install and configure Mozilla: Download a Mozilla build from http://ftp.mozilla.org/pub/mozilla/releases/. For best results, download the Mozilla 0.8.1 build created on 8/28/2001, from http://ftp.mozilla.org/pub/mozilla/releases/mozilla0.8.1/mozilla-win32-0.8.1.zip. Unzip the Mozilla binary files into a new directory on your system. Open a Command prompt and change to the Mozilla bin directory. For example, if the bin directory is in D:\mozilla, enter d: and then enter cd mozilla\bin. Enter regsvr32 mozctlx.dll. If this does not work, the directory containing regsvr32.exe is not in your PATH variable. Use the Windows Find Files utility to locate the program and then run it using the full path; for example c:\winnt\system32\regsvr32.exe mozctl.dll. For more information, see Macromedia Knowledge Base article 9927. http://www.allaire.com/Handlers/index.cfm?ID=9927&Method=Full -- * -- Okay - here are my questions about this information: 1)If references a much older build. 2) It mentions using "regsvr32.exe mozctl.dll" and "regsvr32.exe mozctlx.dll". Note the 'x' after 'mozctl' in the second instance. So my questions are: what is the difference between the two? Which one should I use? What do these dlls do? How are they different? Also - the Macromedia Knowledge Base article is equally unhelpful, by providing different information: It mentions editing the registry to put an entry to the bin directory, which I think does not exist any more (on newer builds.) This article can be found here: http://www.allaire.com/Handlers/index.cfm?ID=9927&Method=Full Any help will be greatly appreciated! Regards, - Jayesh This feature was also available in HomeSite 4.5, but it was difficult to make it work. Easier just to define Mozilla as one of the browsers and use it for real browser preview. As far as the difference between the two, the "...x.dll" is a wrapper around the former dll, but both need to be registered. Good luck. >If you're using the win32.zip or talkback.zip builds After the JRE is >installed on your machine, copy NPJava130_01.dll, NPJava130_01a.dll, >NPJava130_01b.dll, NPJava130_01c.dll, and NPOJI600.dll from the >install directory (something like C:\Program >Files\JavaSoft\JRE\1.3.0_01\bin) to your Mozilla plugins directory >(something like C:\Program Files\ Mozilla 0.9.6 \bin\plugins). It seems that only NPOJI600.dll needs to be copied for Java to work. I got the messenger running in a tab. Opening in a new widow takes more time. Just one problem, the tab has no title. Is there a way to give custom titles to different tabs? By the way to open messenger in a tab the url is chrome://messenger/content/messenger.xul I also made it my Homepage Location so that clicking on Home icon opens the messenger. Several huge performance improvements for opening and closing windows just landed yesterday. Try opening in a new window with the latest nightly! Besides, I don't think opening a chrone URL in a tab is a supported feature. is ist not? It even stood some time ago in Mozillazine news that you could do that. It just works and that's good ;) As you suggested, I grabbed the latest build 2001012806 and now the tabs feature is gone and my bookmarks are overwritten (imported from older netscape bookmarks). Damn, I should start to backup my ~/ #253 RE:Latest build screwes up my prefs, bookmarks andby caseyperkins Thursday November 29th, 2001 3:50 PM Bookmarks weren't overwritten; just go back to the build you had before. Check out recent builds. There is a continuous improvement on leaks and footprint. Browser seems to consume much less (-10% maybe) memory on startup, but this is not the only improvement you may notice. Netscape 6.2 (based on .9.4) has enabled MAPI, so when will the .9.6+ nightlies get mapi enabled? In my 2001112903 build, the option is greyed out. |