MozillaZine

Mozilla 1.3 Alpha Released

Friday December 13th, 2002

Mozilla 1.3 Alpha is out! This release introduces shedloads of new Mail & Newsgroups features (including Bayesian spam classification, message views and improved filtering), a new Bookmarks Quick Search bar (similar to the one found in Phoenix) and support for the Back and Forward buttons on the IntelliMouse Explorer. There's also improvements to the DOM Inspector and lots of other bug fixes. However, remember that this is only an alpha release, so expect bugs.

Builds are available from mozilla.org's Releases Page or directly from the FTP site. Check out the Release Notes for more info.


#1 Re: So Soon after 1.2?

by techn9ne

Friday December 13th, 2002 8:32 PM

Reply to this message

it runs faster than rosie o' donnell when someone walks in w/ a chocolate cake

#2 More bloat

by kinnu

Saturday December 14th, 2002 3:48 AM

Reply to this message

I know lots of people crave spam filtering and all kind of other cool new stuff, but lately I've been starting to feel Mozilla isn't as polished as it was say back in 1.1. Emphasis of development is in adding new features, not in fixing existing bugs. There is big pile of bugs (and by bugs I mean bugs, not RFEs) that really should have been fixed months or even years ago, yet nobody seems to be working on them. Don't get me wrong, I do like some/many of the new features but they tend to be only 95% complete when introduced, and they are never given that final polish to make them 100% functional. Take tabbed browsing for example, a wonderful feature but it's still riddled with small but annoying bugs.

Mozilla needs a cleanup & fixup release sometime in the not so distant future, say 1.5.

#3 Re: More bloat

by oliversl

Saturday December 14th, 2002 4:11 AM

Reply to this message

I agree with you. In past I posted a topic about: "Bug Fixes over Innovation". I love Mozilla and it would be nice if there is a period of time, say 3 months, where all bug are being revised and solved. I'm the only one here having lust dreams about querying bugzilla and getting "Zaro bugs founds"? ;-) Keep up the good work, great release! I'm testing it right now.

#43 Zaro bugs found

by ttfkam

Sunday December 15th, 2002 11:44 AM

Reply to this message

...would only happen if all request for enhancements were omitted from the bug query, all work to performance was stopped, etc. For example, there's (a few) meta bugs about DHTML performance. No matter how fast DHTML gets, people will still want it faster; Therefore, the bug(s) won't ever be closed.

Mozilla's code is freely available and many developers work on it in their spare time for fun or to scratch an itch. Do you really think it's likely that you'll get such a diverse group of developers to simply stop what they are working on when they aren't getting paid for it?

#4 Re: More bloat

by macpeep

Saturday December 14th, 2002 4:40 AM

Reply to this message

I agree, yet don't. I too think that polish is *VERY* important and I too think that there are lots of annoying bugs that should have been fixed a long time ago. For example, I've filed lots of UI bugs that are about pretty obvious and easy things to fix. At the same time, completely new features go in. The "Get Msgs" button was completely riddled with bugs and inconsistencies and disabled itself seemingly on random every once in a while. Bugs regarding it had lots and lots of votes and long discussions, yet nobody seemed to really be bothered about it and instead, there were new mail features like views and "Bayesian filters" and "filter after the fact" that landed. Now don't get me wrong. I understand very well that I'm in no position to demand anything from anyone. And I'm not. People will work on whatever they feel like. I'm just expressing my regret that new features are being worked on while the old ones aren't polished yet.

For example, select the Classic theme on a Windows box and open the mail composer window in 1.3a. Notice how the addressing buttons (To/Cc/Bcc/Reply-To/etc.) look weird. Apparently something went wrong when native theming were enabled and the addressing button suffered to the point where it now looks completely twisted. Now click on the "Address" button on the toolbar in the composer window. Up pops a "Select Addresses" window. Checkout the borders around the big tree widget on the center-left in the dialog. Moving on, close the select addresses window and open up the Security window instead. Notice how the tree column headers are seperated by several pixels from the top of the tree. Also notice how the labels in the column headers have colons in them. There's "Recipient:" when there should just be "Recipient" etc.

In Mozilla Help, click on the "Index" tab on the sidebar. See how there's a narrow Column header above the index? Click on the column header. It reverses the sort order. Now click on it again. Instead of reversing the sort order, the column dissapears. It's been like that forever.

In the Address Book, after native theming was enabled, the borders between the three panes in the window have had really thick borders in the Classic theme, and so on.

Now what I'm wondering is how did these kinds of things go un-noticed? For the most part, these aren't hard to fix issues either, but they are totally in your face. Why aren't these "oops, that new feature made some highly visible collateral damage"-issues repaired before starting to work on new features?

And that's just the UI. There are similar polish issues for functionality too. For example, when a filter moves an email to the Trash folder, the folder appears with bold font in the folder tree in the left pane of the main Mail window. In other words, it's suggesting that there are some undread emails there. However, deleting the email shouldn't cause that to happen. It should also be considered read. And in fact, it IS considered read, but the tree only picks up on it after you enter the folder by clicking on it and then click on some other folder. Only after that does it go back to not being with a bold font.

Enough ranting.. I guess I just think it's sad that old features and the UI aren't being polished. I would love to work on these issues myself but I simply don't have time due to my own job. My involvement is thus limited to testing, bug reports and the occational rant on MozillaZine. I hope people take this as it was meant: as feedback and not as an insult to anyone.

#5 one more thing

by macpeep

Saturday December 14th, 2002 4:43 AM

Reply to this message

The part I forgot to say was what I disagreed with. That's the "1.5" part. I dont think polish issues should *need* a release on their own.

#7 Re: Re: More bloat

by GuruJ

Saturday December 14th, 2002 5:00 AM

Reply to this message

I think the thing to remember is that Mozilla is all about development, *not* polish. Remember, 'binary builds are made for testing purposes only'. Realistically, the polished, bug-free build should be Mozilla 1.0.2 (Netscape 7.01), not any of the more recent builds.

#8 Re: Re: Re: More bloat

by macpeep

Saturday December 14th, 2002 5:29 AM

Reply to this message

That would be a very valid point if it wasn't for the fact that Netscape's releases are almost IDENTICAL to Mozilla. The same bugs, UI or not, polish or not, are in Netscape's releases too. In my post, I could just as well have replaced Mozilla with Netscape but it's kind of pointless since most of the developers are the same and the UI, bugs and features are the same. As it is right now, it's purely semantics to say it's a Netscape release and not a Mozilla release. And there's nothing wrong with that in itself. I just don't think it's very productive to say that "Oh, Mozilla can be unpolished because it's not for end users." because we all know that Netscape's version of Mozilla is 99.999% identical, minus logos and some add ons. If Mozilla is unpolished, it means Netsacpe's release will be.

#10 Re: Re: Re: More bloat

by eiseli

Saturday December 14th, 2002 5:48 AM

Reply to this message

I think you miss the point here. There's a difference between "for testing only" (that is not for end users) and polish. Polish is not about end users, it's about quality. And Mozilla never said they won't make a quality product. Why would they have a QA (Quality Assurance) team then?

#16 and the xul desperately needs polish

by jilles

Saturday December 14th, 2002 10:19 AM

Reply to this message

I've noticed lots of annoying usability bugs with mozilla since I started using mozilla last summer. On the whole I love the browser, appreciate the work that goes into it and the people who do it. However I can't help but wonder whether mpt (<http://mpt.phrasewise.com/>) is right when he argues open source products typically have poor usability.

Type and search for instance is the living proof. It's a cool feature with a not so obvious interface and poor support from the gui. There are many (IMHO) obvious improvements to it that would make this feature more usable. But why prioritize this when even the (popup) menus are inconsistent. Middle click on a link and a new tab opens. Do the same in the sidebar and nothing happens. In fact there is no other way than dragging the link to the tab bar to make such links open in a new tab.

The problem with bugzilla is that these things are not treated as usability bugs (i.e. the useability of the browser degrades) but as requests for enhancements. In most cases the XUL tinkering required to fix it is near trivial, the corresponding bug has been in bugzilla for ages (in some cases from before 1.0) and nothing seems to happen with it.

The usability problems with mozilla are not a technical issue, they are an issue with the way mozilla is developed. It will be interesting to see how phoenix will evolve The development process for that browser is more lightweight than that for mozilla. It seems that (so far), disruptive/unorthodox changes are still possible.

#9 Re: Re: More bloat

by eiseli

Saturday December 14th, 2002 5:37 AM

Reply to this message

"Bugs regarding it had lots and lots of votes and long discussions, yet nobody seemed to really be bothered about it and instead, there were new mail features (...). Now don't get me wrong. I understand very well that I'm in no position to demand anything from anyone. And I'm not. People will work on whatever they feel like. I'm just expressing my regret that new features are being worked on while the old ones aren't polished yet."

I completely agree. Usually, I'm in the same position like you, just triaging bugs, reporting bugs and testing. However, lately I got involved a little bit more, especially with the mycroft project <http://mycroft.mozdev.org/> and thus with the search sidebar in Mozilla. Look at all the bugs in the search component. Most part of them are about the sidebar. This is IMHO the buggiest part in Mozilla, yet if it would be working correctly, you could use it as an argument "look what Mozilla has and other's dont". I'm thinking of the possibility to search several engines in one shot and compare the results in a nice XUL frame. There was one bug, <http://bugzilla.mozilla.org/show_bug.cgi?id=77345> which seemed to be fairly easy to fix, and since the owner of this component, Samir Gehani is overloaded with work, he was grateful I did that XUL polish. He reviewed it. Since it's my first contribution to the code, I wanted to make the things right and got another review from "Mr. Search" at Netscape, Robert John Churchill. He pointed out an easy improvement (adding icons) so I did it. Now it has been over 2 months that I'm requesting Super Review. I have asked several persons to SR the patch, I've mailed the drivers, I've nominated the bug for 1.3a, for 1.3b and what? asa rejects these nominations. (nothing against Asa here, he must have his reasons).

So, in a nutshell: people like macpeep complain about UI polishing, but cannot do the work. Others (in this case me) are doing it. Yet the work doesn't get into the tree for some reason that is _absolutely_ not obvious to me. This reason still has to be named. Believe me, seing my patch lying there for months without being able to do anything is more than frustrating. It's also sad to see that the Mozilla staff doesn't help beginner's code get into the trunk. They'll finally loose their patience and walk away. XUL is easy, anyone can make a lot of UI polishing, but obviously, this is not what the Mozilla team wants. Sad... but true.

#19 Re: Re: Re: More bloat

by WillyWonka

Saturday December 14th, 2002 11:16 AM

Reply to this message

"Others (in this case me) are doing it. Yet the work doesn't get into the tree for some reason that is _absolutely_ not obvious to me. "

I have had the same problem in the past. If you don't follow the hacking mozilla instructions precisely, it won't get it. Also, you have to talk to the right people or else it just sits there. They never seem to reply (at least in my experience) saying "I'm the wrong person for the job" or "I'm too busy to review this patch at the moment". You just sit there waiting and waiting.

"This reason still has to be named. Believe me, seing my patch lying there for months without being able to do anything is more than frustrating. "

I know what that feeling is like.

"It's also sad to see that the Mozilla staff doesn't help beginner's code get into the trunk."

Now, to be fair, they have been working on this a little. On the hacking mozilla pages they now have a link which says "if it's a browser UI issue, send your reviews and super reviews to these people". Also, in the last bugzilla upgrade they added some confusing ?/+/- dropdown boxes which I believe are there to help get bugs reviewed.

"They'll finally loose their patience and walk away. XUL is easy, anyone can make a lot of UI polishing, but obviously, this is not what the Mozilla team wants. Sad... but true."

Most "newbies" (Are you really a newbie if you can help program a browser?) don't realize that actually programming the patch is only 1/4 or 1/3rd of the battle. You also need reviews, super reviews, and sometimes it needs to be approved as well if it is close to a release.

What I think would be helpful is a easy to follow checklist. The hacking mozilla document is too wordy and people skim over it. Maybe someone should redo it and split it up into a bunch of small html pages with hyperlinks for when people need more information on a particular subject. I dunno, just an idea.

#26 Re: Re: Re: Re: More bloat

by eiseli

Saturday December 14th, 2002 1:20 PM

Reply to this message

"I have had the same problem in the past. If you don't follow the hacking mozilla instructions precisely, it won't get it."

Yeah, I think I've read this page a dozen times and also asked on IRC several times as to who to ask. I just e-mailed the contributor-help. Let's see if they can do something.

"On the hacking mozilla pages they now have a link which says "if it's a browser UI issue, send your reviews and super reviews to these people". Also, in the last bugzilla upgrade they added some confusing ?/+/- dropdown boxes which I believe are there to help get bugs reviewed."

Yep, I got all these. Maybe it's an improvement in the "front end". But if the "back end" (the people) are not able to manage that work, what's a good front end worth?

"Most "newbies" (Are you really a newbie if you can help program a browser?) don't realize that actually programming the patch is only 1/4 or 1/3rd of the battle. You also need reviews, super reviews, and sometimes it needs to be approved as well if it is close to a release."

In this sense, yes, I'm a newbie, because I didn't know it's such a battle. I mean sometimes you have controversy in a patch, like "let's do it the other way round..." but here, it's really a minor patch, and no discussion, no controversy. And yes, I'm a newbie at "programming a browser". However I'm an expert about web-authoring (I hate the word web-design, since I'm not a designer) ;-)

"What I think would be helpful is a easy to follow checklist. (...) I dunno, just an idea."

Yeah, but again, the best front-end without a back-end is not worth that much...

#11 Re: More bloat

by mbokil

Saturday December 14th, 2002 6:37 AM

Reply to this message

I think what Mozilla needs now is a freeze on any new features for version 1.4. I would like to propose that 1.4 be dedicated to bug fixing, memory leak analysis, regression testing, and performance optimization. I think every couple of versions it helps to put a hold on new development and dedicate a release to just tightening up a product. If you are into development you know how it works: some modules of code need streamlining but you never have the time. Dedicating time to the schedule and process allows everyone to clean up some of the big messes, in turn making it easier and more efficient for later development.

#12 Re: Re: More bloat & updating Mozilla

by aqua_lon <guardian@gmx.li>

Saturday December 14th, 2002 7:39 AM

Reply to this message

I agree with that.

When talking about more and more new features being added and cause of that introducing new bugs (nobody is perfect) without caring about the older ones, I must always think about Microsoft and the development of Windows.

IMHO Mozilla has enough good features for the moment, but they should really work as planed. A product with thousand of good features doesnīt have any use if you canīt use it on a reliable basis.

I know that most programmers doesnīt really like to fix their bugs and itīs better if somebody works on a new feature instead of doing nothing, but I think all the programmers would get more appreciation if one can use the results of their work without any problems.

And the ONE thing I dislike most at the current mozilla versions is, that you simply cannot update from a version to a newer one without creating a new profile (at least if you donīt want to have some problems). Couldnīt there be a way to automatically update an existing profile to be uses by a new Mozilla version? I would find that very useful and thatīs the thing what really pretends myself from using Mozilla-Mail (I still use Netscape 4.78 for mailing). I donīt have the time to save all my mails and settings before installing a new version of Mozilla and then copy it back afterwards.

It would be really nice to see that at least in the stable Milestones.

#14 Re: Re: Re: More bloat & updating Mozilla

by Sander

Saturday December 14th, 2002 9:29 AM

Reply to this message

>> you simply cannot update from a version to a newer one without creating a new profile (at least if you donīt want to have some problems) <<

You can't? Strange, that's exactly what I've been doing since 0.9.2, and I download a nightly or two a week... Just as long as you install each build in a new directory your profile should remain completly usable...

#15 Re: Re: Re: Re: More bloat & updating Mozilla

by aqua_lon <guardian@gmx.li>

Saturday December 14th, 2002 10:02 AM

Reply to this message

hm... I had some problems after updating, but if I remember correctly I havenīt installed Mozilla in a new directory and I always thought the problems were because of the old profile since they were away after creating a new one.

I donīt really know so much about programming, but as I understand it all settings are saved in the profile. So I would think all older files in the installation directory are overwritten during the installation and should make no problems. Or can there be problems with files of older version which are not used in an newer build?

#20 Re: More bloat & updating Mozilla

by WillyWonka

Saturday December 14th, 2002 11:25 AM

Reply to this message

What I do, and I never run into any problems is, I stick mainly to the a, b, and final releases, but when I install them I uninstall the previous mozilla first via add/remove programs (win2k). Then I go into the directory and look to see if any files are left behind that are not needed there. If there are, I delete those too. Then I run the install for the new version and install it in the same directory (in my case c:\program files\mozilla). Then when I run mozilla, all of my settings are still in place and my email is all there. I've never had a problem.

Now when I install nightlies, I use a second profile just to be on the safe side.

#27 installing over older builds

by Sander

Saturday December 14th, 2002 1:24 PM

Reply to this message

99% of the problems with upgrading mozilla versions come from installing over older builds. Some files are not installed but only created when you run mozilla, others change name (and thus the old versions aren't overwritten). Practically the first thing you do when triaging a certain type of unconfirmed bug report is asking the reporter if he installed over an older version...

The following two lines have been part of the mozilla release notes for as long as I can remember:

Installation Notes Install into a new empty directory. Installing on top of previously installed builds may cause problems.

'course, people don't read the release notes... *sighs* :)

#30 True, but...

by bmacfarland

Saturday December 14th, 2002 5:12 PM

Reply to this message

I've been installing over builds since about .9 and only ran into trouble twice. I'm not into bug reporting yet, haven't found a lot that I can report yet. What reason is there to not install over a previous build when they work more than fine for me, 95% of the time?

#32 why?

by eiseli

Sunday December 15th, 2002 12:20 AM

Reply to this message

Because of the other 5%

#22 Re: Re: More bloat

by mesostinky

Saturday December 14th, 2002 12:01 PM

Reply to this message

"I would like to propose that 1.4 be dedicated to bug fixing, memory leak analysis, regression testing, and performance optimization"

I agree. I think Mozilla is feature complete enough where now its time to fix many of the lingering bugs which have been around for a while. I also think there are regressions that are causing memory and stability problems that were not there recently.

#38 I disagree

by AlMalossi <AlMalossi@gmx.net>

Sunday December 15th, 2002 9:56 AM

Reply to this message

A whole .x version number just for making it polished and even more stable costs 3 month! That's a lot of time to 'sacrifice'.

I think Mozilla needs a few more outstanding features to be a reason to change. Look for typeahead for instance, birlliant feature needs more publicity. And the calendar module will make it more attractive.

A lot of Mozillazine reader complained (at the time of 0.9.x) a lot of about the mail client, but mainly for speed. But the press complained about, there is nothing special in this mail client (at the time of 1.0) . Now the developers respond in bringing new (partly unique) features, and the Mozillazine community seems to dislike 'progress' in features at all.

For the one who just needs a stable stable stable and quite well polished browser/mail client/composer/addressbook there is the 1.0.x branch. I personally love to see feature progress in the 1.x trunk

#40 Re: I disagree

by mesostinky

Sunday December 15th, 2002 10:43 AM

Reply to this message

" For the one who just needs a stable stable stable and quite well polished browser/mail client/composer/addressbook there is the 1.0.x branch. I personally love to see feature progress in the 1.x trunk"

Who wants to use 1.0x though? In downgrading to 1.0x you lose a lot more than speed.

"Mozillazine community seems to dislike 'progress' in features at all. "

That's just not true, and you obviously don't know much about the people here who have been using and testing Mozilla for a long time. Most people here at the Mozillazine love progress and cool new features. You must not come here often to believe something like that. But like I pointed out, right now we are at a point where there are some ancient bugs needing fixing and possbily some regressions causing stabilty problems. These need to be fixed before we move on and my post isn't about what you accuse me of.

#44 Re: Re: I disagree

by AlMalossi <AlMalossi@gmx.net>

Sunday December 15th, 2002 11:47 AM

Reply to this message

"you accuse me of." hey never wanted to get personal, sorry if i left this impression.

I'm maybe not so often like you in the talkback (but i'm reading mz daily) but it's simply fell into my eyes that after the annocement of "1.3a is out" there is a huge thread "More Bloat" in the talkback. Maybe I'm just missing the "Hey that's great release", "Cool Feature", ... posts which normaly are present at Mozillazine when a new release is out.

That's a alpha release of 1.3. The mozilla roadmap wants exact this cycle that new features are introduced in the alpha release.

I'm coding too (no not mozilla), and I know that bug tracking is 100 times more boring than implementing of new features. And since mozilla is a open source project I can not 'demand' from coders to drop all the fun things. Yes I am aware of how important stability is

Mozilla is not only about creating rocksolid application it want's to gain the momentum of open source volunteer.

And yes one can start now a reply about "most of them are aol employee anyway"

#50 Re: I disagree

by aqua_lon <guardian@gmx.li>

Monday December 16th, 2002 1:44 AM

Reply to this message

"That's a alpha release of 1.3. The mozilla roadmap wants exact this cycle that new features are introduced in the alpha release."

Thatīs true and I think nobody would expect to have a alpha version that works correctly and stable. New features are always good if they are useful for your work and there are many things from Mozilla-Addons that would be good to have in the normal builds (like Tab-Enhancements, Crash-Recovery...). But I also think, that new features doesnīt have much use if you canīt use them cause of a lack of usability or an old bug.

I personally would like to see some polish of the code, but I donīt demand anything from the programmers. They did and still do a very good job in making Mozilla a very good application and I really appreciate that. In the end itīs their decision how to go on.

#13 Re: More bloat

by mbokil

Saturday December 14th, 2002 7:40 AM

Reply to this message

I think what Mozilla needs now is a freeze on any new features for version 1.4. I would like to propose that 1.4 be dedicated to bug fixing, memory leak analysis, regression testing, and performance optimization. I think every couple of versions it helps to put a hold on new development and dedicate a release to just tightening up a product. If you are into development you know how it works: some modules of code need streamlining but you never have the time. Dedicating time to the schedule and process allows everyone to clean up some of the big messes, in turn making it easier and more efficient for later development.

#24 Re: Re: More bloat

by bzbarsky

Saturday December 14th, 2002 12:31 PM

Reply to this message

Which part of mozilla?

For example, the layout engine has been in just such a freeze for oh, at least half a year now. We're hoping to start making some radical and much-needed changes in 1.4.

#18 Re: More bloat

by Kob

Saturday December 14th, 2002 10:26 AM

Reply to this message

Relevant comments are in the MZ Forums - Mozilla Bugs ( thread "dhtml cnet.com banner ad")

#6 I agree

by simifilm

Saturday December 14th, 2002 4:54 AM

Reply to this message

I agree to some degree. While I really love additions like "filter after the fact" and junk filter I'd also love to see some obvious bugs fixed. I think everyone of us has some bugs he really hates but which would be quite simple to fix. Two things that annoy me: when I get mails and the filter moves them to my different folders and I read them afterwards I always have to green arrow showing. Even when all mails are read. I have to go back and select to inBox to have it disappear. Moz doesn't see that all mails are read. Another thing: Moz cannot import its own Mails. I know you can do that by hand by simply copying the file but an import function would be a real no brainer.

I think it would be nice to have some kind of 1.5.x tree like the 1.0.x we have now. Freeze the current feature set and do some polishing.

#17 I disagree

by Galik

Saturday December 14th, 2002 10:21 AM

Reply to this message

I thing Mozilla 1.0, 1.01 are for stability/polish. For "next generation" Moz I would like to see all kinds of top notch, killer useful things that make life on the net not just good but fantastic. There's plenty of time before, say, a 1.5 mabe that can accumulate polish but whenever it does get the final polish I WANT those cool, inovative and fantastically useful features in the product. Why would I migrate from stable 1.0x to (say) stable 1.5 if the're arn't any compelling reasons such as it does soooo much more? Go Moz-team add the features 'cos I can wait for the polish. Frankly I'm on 1.3a now and It's been like totally stable for me! What more could I want from stability? So give me the features :)

#21 Re:

by plwong

Saturday December 14th, 2002 11:43 AM

Reply to this message

Mozilla is now reasonably (if not very) stable even for its nightly builds (which I download once a day in office..). But optimization of speed is very important. I've been trying to convince some friends to use Mozilla/Phoenix. But after they try it, most of their answer is that Mozilla 1.3 and Phoenix 0.5 is just too slow as compare to IE. They say they'll consider switching only if it's as fast as IE. There's certainly many people who care about speed much more than features becasue they don't use those features....

#31 Re: Speed

by oliversl

Saturday December 14th, 2002 9:16 PM

Reply to this message

Mozilla is as fast as IE rendering html, sometime ever faster. But maybe you are reffering to the launch speed of Mozilla and memory usage. Rendering speed and launch speed are different issues, remember that to your friends. ;-)

#33 speed

by roman

Sunday December 15th, 2002 1:06 AM

Reply to this message

Last time I tried Mozilla, it still took a long time to display its own menus and dialogs. That only happens with Find dialog and bookmarks in IE. Shit, do I hate that! I use Opera often. It's fast, reliable enough, and it's multiwindow.

#37 Re: Re: Speed

by Kob

Sunday December 15th, 2002 8:25 AM

Reply to this message

Yes, Mozilla is noticeably slower on DHTML. There are numerous speed-related DHTML bugs posted on Bugzilla. There is progress since the 1.0 days, some even very substantial, but it is still way too slow compared to IE. I can provide real-life examples of 2:1 and even 3:1 speed ratio advantage IE:Mozilla/Phoenix and I am not talking about esoteric stuff.

#35 Re: Re:

by javaman67 <javaman67@acd.net>

Sunday December 15th, 2002 6:11 AM

Reply to this message

If I'm not mistaken, the reason IE loads so fast is due to pre-loading during the OS bootup. When you have 90% of IE already in memory, it doesn't take long to bring up the last 10%. However, there is the tradeoff of loading down your system with too much pre-loading going on. It's all perception and no substance when it comes to the initial load times any more.......Mozilla and Pheonix are pretty fast now.

#36 Re: Re: Re:

by jilles

Sunday December 15th, 2002 7:34 AM

Reply to this message

>If I'm not mistaken, the reason IE loads so fast is due to pre-loading during the OS bootup.

This is a myth. After you launch mozilla the first time, you lose this advantage and it still feels slower after that. The real reason mozilla feels slower is the overhead of XUL. XUL is nearly as fast as native components. However, there are these barely noticeable delays that add up and the slight inconsistencies with the native behavior that users notice.

There are a few moments I always notice Mozilla is slower than IE" going back and forth between pages. When you click back in mozilla, there is a few hundred millisecond delay (enough to notice). In IE the response is much quicker. A similar delay can be observed when clicking links, scrolling, opening new windows, new tabs, etc. It's not so much the loss of time that gets annoying but the awareness that things slow down momentarily.

The mozilla developers have done a great job optimizing gecko (which also handles the XUL). The performance degredation used to be much worse. In fact, I find that the 1.2 and later versions of mozilla are noticeably faster than the 1.0 series. However, IE has been gaining weight. In windows XP there are all sorts of themes and animations slowing down the UI. I think this will become much less of an issue as gecko & hardware become faster.

#39 Re: Re: Re: Re: IE6 is slower too

by AlMalossi <AlMalossi@gmx.net>

Sunday December 15th, 2002 10:09 AM

Reply to this message

Personal opinion:

IE6 is also bloated with new features and is slower in the parts where it's integrated in the OS very tight. I recently had to update from IE5.5 to IE6 on a win2k computer, and I experience this small annoying delays, you were talking about in Mozilla, in my Windows Explorer.

So at least Mozilla is not the only one on the wrong track.

I think that's the price you have to pay if you want the good technology in the back XML-XSLT, DOM and don't only want a fast rendering of yahoo.com

#42 Re: Re: Re: Re:

by asa <asa@mozilla.org>

Sunday December 15th, 2002 11:43 AM

Reply to this message

>If I'm not mistaken, the reason IE loads so fast is due to pre-loading >during the OS bootup.

>>This is a myth. After you launch mozilla the first time, you lose this >>advantage and it still feels slower after that.

The poser said "the reason IE loads so fast is due to pre-loading". How is it a myth that initial startup for IE is affected by it's pre-loading? You're denying that IE improves startup by using already loaded libraries? The poster suggested that IE's startup was so fast because it saved a lot of time on initial launch by being pre-loaded and you responded that IE pre-loading improving IE's initial launch time is a myth. Am I reading that wrong?

Mozilla's quicklaunch demonstrates that if you've already got most of Mozilla in memory that it can be very competetive with IE at initial startup. On my range of PCs (from 500Mhz with 128 MB RAM to 2.2Ghz with 1GB of RAM and several in between) Mozilla's start time, using quicklaunch, and new window time is very competetive with IE6. IE has a slight advantage but over my full workday (and I use a browser a lot for my work) I probably close and start a browser between 10 and 20 times and I'd wager that IE's startup advantage would save me no more than about half a minute each day. I save at least several times that much time with just one of Mozilla's time-saving features - being able to load several pages as my start page. With my usage, IE is considerably slower to startup and become usable (in which I include loading start pages) because with IE I have to launch several windows, switch between them, and click a bookmark menuitem or toolbar link for each of my several start pages.

>>The real reason mozilla feels slower is the overhead of XUL. XUL is >>nearly as fast as native components. However, there are these >>barely noticeable delays that add up and the slight inconsistencies >>with the native behavior that users notice.

It's worth noting that IE browsers don't all use native widgets either. IE uses a special set of widgets in at least version 4 and 5 but they're darn close to the OS set so as to not be noticed by most users. With the creation of the nsITheme code, Mozilla's widgets are also getting very close and should continue to get even closer (at the same time MS is deviating even further from native. See recent releases of WMP).

>>There are a few moments I always notice Mozilla is slower than IE" >>going back and forth between pages. When you click back in mozilla, >>there is a few hundred millisecond delay (enough to notice). In IE >>the response is much quicker.

And this has what to do with XUL performance? I'm no engineer so I'm not an expert in these areas but I've been involved long enough with Mozilla to know the basic difference between issues of startup performance (time it takes to load the various modules like nspr, necko, jsengine, layout, xpcom, nss, dom, toolkit, etc. into memory + time it takes to render the initial interface and content) UI performance (UI widgets with performance tied to layout, style system, image libraries, dom, JS, etc) and back and forward performance (time it takes to pull data from the cache, fetch any necessary changes from the net, rebuild the dom, layout the page, etc.). I fail to see how your issue of back and forward performance is in any way related to your claims that "the real reason mozilla feels slower is the overhead of XUL" or how it has anything to do with the poster's comments about initial launch times. Back and forward performance could be improved with zero changes to XUL. One possible improvement could be to cache the entire dom of the page along with the page content and save the time it takes us to rebuild that DOM. I believe that Opera does something like this to improve their back perf. Most suggestions I've heard have everything to do with cache design or performance and nothing to do with XUL performance.

>>A similar delay can be observed when clicking links, scrolling, opening >>new windows, new tabs, etc. It's not so much the loss of time that gets >>annoying but the awareness that things slow down momentarily.

I don't see any significant slow down when creating new windows or tabs. Maybe my hardware (some of it more than several years old) is just good enough for this to not be a problem.

>>The mozilla developers have done a great job optimizing gecko (which >>also handles the XUL). The performance degredation used to be much >>worse. In fact, I find that the 1.2 and later versions of mozilla are noticeably >>faster than the 1.0 series. However, IE has been gaining weight. In windows >>XP there are all sorts of themes and animations slowing down the UI. I think >>this will become much less of an issue as gecko & hardware become faster.

I agree with all of that. I think it's also useful to compare the performance of our current technology with say M18 or M14 (on which Netscape 6 and NS6 PR1 were based, respectively) because so many people got their first impressions of Mozilla performance when they tried those corresponding Netscape releases. I did this back when we were getting ready to release 1.0 and while it wasn't a surprise to me the performance improvements were dramatic. I believe that 1.0 was sufficient for most hardware released in the last 5 years (about the time the 6th generation processors started to penetrate the market) and agree that 1.2 and beyond are noticeably more performant than 1.0. I also agree with you about hardware getting faster. My personal opinion is that if Mozilla was to ship as a default Browser on a new, say Dell, machine that users wouldn't have any significant problems with Mozilla's performance. All but the bottom of the budget PCs are coming with 2-3GHZ processors 256MB RAM or more and even the budget PCs are shipping with at least 128 MB RAM, not to mention that you can add .5GB of RAM for between $30 and $150 depending on your particular flavor.

Mozilla needs to continue to improve in performance. Phoenix has demonstrated some pretty significant startup and new window performance(as well as sidebar and other widgets). But raw speed isn't always the answer, at least not the only answer. A few simple examples can point out where real-world usage performance and raw speed measurements don't alway equate. My example above about being able to load several pages in tabs at startup is one. Another is page load where we have preferences for how fast gecko throws something up to the screen that trades off with how fast gecko finishes the complete load of the page. People who set this timeout to something really low or zero all seem to think that it's a huge improvement in pageload speed even though it can slow down the actual total pageload time significantly. A third example is pop-up controls. I'll bet that there's at least some tiny performance implication for by including this feature but the time it saves a user in dealing with annoying popups I think is a huge win in saving users not just aggrevation but _time_.

We need to be thinking about more than just these raw performance numbers because startup or pageload numbers may mask the real speed with which users are able to get things done in the browser. If we're not offering a tool that makes browsing a better and faster experience then people won't use it. I think we're on the right track with incrementally improving raw performance and at the same time adding features which help users accomplish their browsing tasks faster.

--Asa

#23 A single feaure over polish

by flacco

Saturday December 14th, 2002 12:02 PM

Reply to this message

I'd be glad to take up a scuffed-up Mozilla with roaming profiles than a polished one without.

#25 Re: A single feaure over polish

by rwc

Saturday December 14th, 2002 1:02 PM

Reply to this message

Hear, hear! My company currently has Mozilla as the default browser, PLUS a "Guest" icon for roaming bookmarks and e-mail. How stupid is that?

#28 Makefile (I hate typing!)

by hubick <chris@hubick.com>

Saturday December 14th, 2002 2:15 PM

Reply to this message

RSYNC_RHOST := archive.progeny.com RSYNC_RDIR := mozilla/releases/mozilla1.3a/Red_Hat_8x_RPMS/xft/RPMS/i386/

RSYNC := rsync -v RPM := rpm

rsync: $(RSYNC) -r $(RSYNC_RHOST)::$(RSYNC_RDIR) .

RPMS := $(wildcard ./*.rpm)

upgrade: $(RPM) -U $(RPMS)

#29 Live, Feature Status Update, live!

by arnoudb <arnoudb@dds.nl>

Saturday December 14th, 2002 4:13 PM

Reply to this message

What I'd *really* like to see return here on MozillaZine is the 'Feature Status update' we once had (like in around the Moz-0.9 days - see <http://www.mozillazine.or…articles/article1922.html> for what they were like). Back then James Russell would post a quite comprehensive overview, for every milestone or so, about exactly what was going on with Mozilla at a 'higher level'. While Bugzilla and Mozilla.org's status update are great for finding individual bugs that are being worked on, it's sometimes hard to see the general direction into which the whole Mozilla project is going in term of planned new features, or overhauls of components that are being worked on. The 'Feature Status updates' used to provide exactly that information. I think a lot of the general unhappiness often seen here like "Why is feature xxx being added while the GUI in component zzz has all these bugs?", stems from this lack (or hard-to-find-ness) of this information that makes it clear and understandable for all of us here as to why the focus is in certain areas and not on others for a certain milestone.

Just to give an example, I just learned from bzbarsky's post above <http://www.mozillazine.or…le=2751&message=24#24> that there will be some 'radical and much-needed changes in [milestone] 1.4' to the layout engine. While this is great news, and I can see or guess at the need (DHTML bugs? Table border bugs? CSS Outline bugs? just to mention a few very persistent layout problems), it is much less clear *what* exactly will be the focus of these changes (are they indeed to fix the unsolved rendering bugs we have that I just mentioned, or will it focus on performance?) and *why* exactly this is planned for milestone 1.4? Why was it not scheduled for 1.3? Why not 1.5? If 1.4 will focus on layout, what will be focussed on for 1.5? It seems 1.2 and 1.3a had a great (and much appreciated!) focus on Mail/News, but nothing made that as clear as the release notes did! Which is fine, but it would be nice to see this direction of development at the beginning of the milestone, instead of when it is being released.

#34 I wouldn't trust Mozilla to decide what is junk

by roman

Sunday December 15th, 2002 1:09 AM

Reply to this message

It doesn't even tell you when you are out of disk space! I wouldn't trust it to decide what is junk mail and what is not. I don't want to lose my data.

#41 Read this then

by arnoudb <arnoudb@dds.nl>

Sunday December 15th, 2002 10:49 AM

Reply to this message

<http://www.paulgraham.com/spam.html> Very good explaination about how it works, and why it works as well as it does.

#51 Re: I wouldn't trust Mozilla to decide what is jun

by mbokil

Monday December 16th, 2002 5:46 AM

Reply to this message

I think this user has a valid point. Mozilla 1.3a is pretty good now and stable but there are still some potential data loss bugs such as running out of disk space wich to my knowledge have not been fixed yet. So while cool new features are great I would still like to see a possible freeze on the 1.5 branch so it can increase in stability without any new features.

#54 That's not what was being said

by arnoudb <arnoudb@dds.nl>

Monday December 16th, 2002 8:45 AM

Reply to this message

The user said he 'didn't trust Mozilla to decide what is junk, [because] he didn't want to lose any data'. While I can understand not wanting to lose data, that point was completely invalid. All Mozilla does is *mark* a message as spam, or not spam, and then the user can decide what to do with it by means of filters. Want to be on the safe side? Fine, just let Mozilla move spam messages to a separate directory for a while, until you gain more trust in it. You'll see it hardly ever makes mistakes and never any false positives once you've trained it with a good amount of spam and non-spam messages.

#55 Filtering spam

by roman

Monday December 16th, 2002 1:01 PM

Reply to this message

I bet I can write a legitimate email message that your spam filter would mark as spam. For example, if I emailed you and others who think the same way about identifying spam something like this: "Hey, friends, I thought you should take a look at this -- <http://read-how-spam-filt…-miss-legitimate-mail.com>", I am sure your spam filter would mark that as spam.

Now, if your email program moves spam messages to a seperate folder, and you have to look at messages in it to see if legitimate messages haven't been falsely accused of being spam, what's the point in having the spam filter at all? Just place them in your main Inbox folder, and manually analyze messages and delete spam.

#56 Re: Filtering spam

by asa <asa@mozilla.org>

Monday December 16th, 2002 5:15 PM

Reply to this message

So give it a try then. Write me with something I should be interested in and try to make it look like spam. Send a followup to me announcing the content of the spam-like mail and I'll let you know what happened. I suspect it won't get marked as spam. See, the Mozilla bayesian spam filters look at more than just the body and they're designed to avoid false positives. I've sent myself your message, copied pretty much exactly as you posted above and sent from several newly created webmail accounts (hotmail, yahoo and netscape) and had none of them marked as spam.

--Asa

#58 Not spam

by arnoudb <arnoudb@dds.nl>

Tuesday December 17th, 2002 10:07 AM

Reply to this message

I tried the same as Asa did, and no, your message did not get marked as spam.

If you had actually read the article that I posted above, you would have known why not. In fact, the article mentions the very example you mention, that the only way for spammers to beat the filter might be to change their message to something neutral-looking like "Hey, friends, I thought you should take a look at this", but even then, the headers in their message, and probably their url too would give them away.

#59 Re: Not spam

by roman

Thursday December 19th, 2002 9:35 PM

Reply to this message

I used that example because I read the article (not completely but enough to get the gist). And I am pleasantly surprised that the algorithm didn't mark that message as spam. Does it analyze headers? If so, then that might explain why. I've looked at several spam messages and even replied to several. They don't usually (probably not all) send from where they say there are, and their email addresses are nonexistant.

Do you trust this algorithm enough to simply delete messages marked as spam?

#45 Spam Filtering

by WillyWonka

Sunday December 15th, 2002 1:27 PM

Reply to this message

Damn, I just got a false positive with the spam filtering :( I thought it would be better than it is.

#46 Re: Spam Filtering

by asa <asa@mozilla.org>

Sunday December 15th, 2002 2:54 PM

Reply to this message

Did you train a large number of known bad and known good mail? I trained about 5,000 spam messages and about 15,000 not spam messages when I first moved to the builds with bayesian filtering (I was saving up spam in a special folder in anticipation of the new feature). I get about 500 messages a day and lately I'm getting about 90% success in flagging spam with not one false positive to date.

--Asa

#47 Re: Re: Spam Filtering

by niner

Sunday December 15th, 2002 3:12 PM

Reply to this message

thousands? I just showed it about 10 or 15 spam mails and a handful nonspam and it takes the right choice nearly every time. But maybe that's just because the only english mail I get is through some mailing lists and Bugzilla, the rest is German so it should be easy to differ.

#48 Re: Spam Filtering

by WillyWonka

Sunday December 15th, 2002 3:16 PM

Reply to this message

My spam folder is 39mb but the amount of actual email I recieve is a lot smaller than that. I think that's why it's favouring the spam.

#49 I *loooove* spam filtering

by GuruJ

Sunday December 15th, 2002 6:43 PM

Reply to this message

Or at least the idea of it. I'm prepared to give Mozilla a bit of time to get its act up to speed ... but it's certainly a real innovation that not many other mail clients have yet.

#52 Mail window doesn't open in 1.3a

by Trucoto

Monday December 16th, 2002 6:20 AM

Reply to this message

I just installed 1.3a (previously deleting 1.2 folder), and the mail window doesn't open. Any ideas?

#53 Now things are really serious

by Trucoto

Monday December 16th, 2002 6:29 AM

Reply to this message

I uninstalled 1.3a and reinstalled 1.2, and I still have no mail! Please help me...

PS: I checked with a new profile and everything works perfectly, in 1.3a and in 1.2. But something got messed in my real profile after I installed 1.3a.

#57 Re: Mail window doesn't open in 1.3a

by nuopus <nuopus@cox.net>

Tuesday December 17th, 2002 1:35 AM

Reply to this message

First of all, in Windows 2000 and XP, make sure you are set to view all hidden files (not default). Go to your C:Documents and SettingsUsernameApplications and delete your old Mozilla directory. You don't have to un-install, just close Mozilla, delete and re-open. It should work fine after that. BTW I am running 1.3a installed on top of 1.2 and it works perfectly if you remove that old dir. Just make sure to export your bookmarks so you can import later.