Mozilla Milestone 14 Awaits

Anderson Silva (among others) zapped us the news that you can now grab Mozilla's M14 release (Seamonkey). The Mozilla Organization's site doesn't yet reflect M14's availability, but it will soon. For now, here are the release notes. So grab, test, and gripe -- bug reports will only make the Mozilla browser better.

Comments

Re:Mirrors (Where?)

[fluffhead]

Check out http://www.mozilla.org/mirrors.html for a list of download mirrors.

#include "disclaim.h"
"All the best people in life seem to like LINUX." - Steve Wozniak

This better not be M14

[slag187]

So, I downloaded the M14 for Linux (with Talkback support). All I can say is - huh? I ran it for maybe 15 minutes and have had it crash already a dozen times - even on pages that are supposed to be verified (like www.cnn.com).

I know that this is alpha software, but my impression of the road to M14 was supposed to make it so that people could use it as their full time browser - and thus squash more bugs.

It crashed the first time I loaded it before getting through the profile creation process.

I've been rooting for Mozilla for a long time now and have been apologetic - I keep telling people to give them a month or two, to wait for the next Milestone. I was very disappointed with it as I had had high hopes for this release (which has been much touted as the push for stability). Am I the only one? Was it built against different shared libraries than what I'm running? Is it better than Netscape 4.7 for anyone (which I've heard before)?

Well, I give up for now - I'll wait until the official launch and see how it is then . . .

I'm jaded :^\

Re:This better not be M14

[Slothy]

The problem here is that you're using an SMP box and Mozilla is not yet thread-safe, though I have NO idea why they don't put this is big bold letters on the M13/14 pages. So people with a single CPU have a fairly rock-solid browser, and people with SMP boxes think this should probably be Milestone 3.

The bug for this is:

http://bugzilla.mozilla.org/show_bug.cgi?id=2155 6

Use a talkback build

[linuxci]

If you're using Windows or Linux please consider downloading a talkback build (they have talkback in their filename) this'll automatically send back crash data (with your permission - a box will appear first) to the Mozilla team which will help them track down the main causes for Mozilla to crash.

BTW the source code for M14 should follow on the FTP site soon. If you can buld for other platforms please do so and contribute your builds back to Mozilla. See here for details of packaging your own milestone build for your platform.
--
Make use of your spare CPU time!

Re:Use a talkback build

[Simon Brooke]

I've been using talkback versions of Mozilla since about M8, I think - it doesn't always work. In my experience four out of five crashes go down so hard and so fast that talkback never gets a chance. Maving said that, M13 was in my opinion very nearly as stable as 4.7 - but having said *that* I've now ditched 4.7 in favour of 4.6, because I found 4.7 so fragile as to be more or less unusable.

M14 already? What happened?

[drivers]

But there are still 500 bugs targeted for M14

I saw M13 get whittled down to zaroo boogs, then it came out, I assumed the same for M14. Does this have anything to do with Netscape wanting to get a Communicator 6.0 beta out ASAP?

Don`t forget about Mozillazine!

[Sits]

Mozillazine is a website manned by helpful volunteers hoping to make Mozilla the best browser possible. If you are unsure as to how to get started bug testing, I recommend stopping by #mozillazine for a friendly chat.

Re:Fonts still AWFUL!

[Ungulate]

The problem is really with the abysmal state of fonts in X in general. The best thing any person using Netscape under X can do for themselves is get the Microsoft web fonts and install them. Web pages look dramatically better in both Netscape and Mozilla.

xfstt is probably the easiest X truetype font server to configure. If you went nutty trying to get the patched xfs in RedHat to work, give xfstt a try.

nightly builds

[miahrogers]

I've been using last-night nightly build for the last several hours, and (on my machine) it hasn't crashed. I know that on some machines the luck is not so good. But I'm using a newer version of glibc than the computer that built it was(i use libstdc++-libc6.1-2.so.3 and it was built for libstdc++-libc6.1-1.so.2), i had to symlink the libs, and it still works great.

Note: If you are using woody, until the debian build comes out mozilla won't run out-of-the-box on your computer, symlink libstdc++-libc6.1-1.so.2 to libstdc++-libc6.1-1.so.2 , then it should work(at least it did for me).

Bug Reports

[asa]

Mozilla releases these milestone checkpoints with the hopes that lots of people will take a look and give some feedback. Bug reports are the best way to give this feedback. Mozilla's bug database Bugzilla (located at http://bugzilla.mozilla.org ) provides some really nice tools for reporting bugs and feature requests. Before reporting any bugs it is a good idea to give the database a query to see if your bug has already been reported. This will save mozilla QA a lot of time weeding through duplicate bug reports. You can search the database at http://bugzilla.mozilla.org/query.cgi . Start off with simple searches in the Description field. If that yields too many bugs to weed through you might add more to the search. If you find your bug reported please add any relevant comments to that bug report. If you find that your bug is not reported then please take a quick glance at the bug reporting guidelines before making your report. These guidelines will help you report a bug that developers and QA can track down and fix more swiftly. The bug reporting guidelines ca be found at http://www.mozilla.org/quality/bug-writing-guideli nes.html . If you are new to the process you might try the new Bugzilla Helper which will guide you through the process. Remember that the better the report the more quickly it will get confirmed, assigned and fixed. Thanks, and enjoy M14 (for those that like to stay on the bleeding edge, M15 cycle nightly builds have been available for a few days now.)

Asa
external QA on the Mozilla project

irc log from last night (edited)

[Anonymous Coward]

#mozilla topic: "sarcasm is just another service we provide"

<Icos> Does anyone want to throw in a quote for my article on M14's release? (hint: say yes!)
<alecf> "At least you don't have to reboot twice to install it"
<tor> "It sucks less than previous milestones"
<Pavlov> "Don't run it on SMP systems."
*** Quits: Icos (Greg@hyper2-61.wctc.net) (Read error: 131 (Connection reset by peer))
<alecf> heh
<alecf> we scared him off
*** Joins: Icos (Greg@hyper2-61.wctc.net)
<Icos> bah
<Icos> I was thinking more along the lines of "We here at Netscape are proud of the great new features of M14 and look forward to delivering an impressing beta"
<Icos> Sigh.
<Icos> nobody likes the press.

mozilla.org front page might not show m14...

[jesser]

but the release notes are up.

--

Protocols supported

[linuxci]

As well as the protocols you'd expect to be supported some outside contributors have also added the daytime protocol (although they've wrongly called it the datetime protocol) and the finger protocol. There has also been work at implementing the IRC protocol.

Try clicking on the following links in Mozilla:

Finger

Daytime (site may be down in a few hours though so if it doesn't load it's probably not mozilla)

I can see a use for the finger protocol (if all major web browsers end up supporting it there'd be no need for those finger CGI scripts that people use to view .plan files on the web)

--
Make use of your spare CPU time!

testing vs. personal use

[SEAL]

Why should you download the latest Mozilla milestone?
Don't say for personal use... it is still in a testing phase.
You have to remember that the developers are counting on your input.
Pour over the little details and give them feedback.
Some of the crash bugs need to be endured - don't go screaming back to I.E.
Hot off the press builds (nightlies) should probably stay with the developers, however, who have more
Grits to deal with the situation.
Down to the last milestone, you have to think like a tester, not an end user.
Your feedback is important to the Mozilla team.
Pants off to them... er whoops ;) Hats off.

SEAL

(sorry I couldn't resist...)

Re:Blame it on XPToolkit?

[WackyTJ]

No..

Actually that GFX controls and the XPToolkit is almost required. it offeres the following advantages

-Ease of portability
-reduced "hard coded" interface routines..

but the most important thing..

CSS requires styles to be applied to controls, such as "blink" strikethrough etc... this cannot be handle by ALL native controls in ALL target platforms of Mozilla, so the GFX controls, and XP toolkit, is almost required... there is no other way.. Even IE uses a similar thing to the XP_Toolkit.. but a more proprietry one.

Re:I'm gonna get flamed for this ...

[PurpleBob]

What a lovely comparison. Reminds me of this review for Douglas Adams' "The Long Dark Tea-Time of the Soul":

"Funnier than Psycho, more chilling than Jeeves Takes Charge and shorter than War and Peace..."

--

OT: Slashdot speed (was 'any hope for the speed?')

[orcrist]

I'm very surprised that Rob hasn't implemented Gzip::Chain for Slashdot. For those of you who don't now what that is, it's a modperl handler which gzips the output before sending it. This takes advantage of the single most unused feature of Unix Netscape, namely gunzipping pages on the fly. Given the huge amounts of text on most Slashdot pages, as well as the above-average use of Unix Netscapes by Slashdot visitors, I figure this would be a very significant improvement in speed for said users, not to mention reduced bandwidth usage. Of course, I'm not sure how much CPU time that would require on the Slashdot servers, though I assume bandwidth is more of a bottleneck.

Just a thought which I keep on meaning to mail Rob...

Chris

Re:OT: Slashdot speed (was 'any hope for the speed

[Zico]

I don't think that any benefits would be worth the extra load on the server compressing all this dynamically-generated data, though. Especially because I don't think the benefits would be too drastic for most users. A lot of users (I'd guess most) have net connections (modems, isdn adapters, etc.) that already perform decent text compression between them and their ISPs. Just my opinion, corrections welcome

As an aside, IIS 5.0 (maybe 4 as well, I'm not sure) also supports compressing sent data -- any idea if Netscape can handle this as well?

Cheers,
ZicoKnows@hotmail.com