Mozilla 1.4 Beta Released

Thursday May 8th, 2003

Mozilla 1.4 Beta was released yesterday. This release allows you to separately specify whether a blank page, your home page or the last page you visited loads when you initially start Navigator, open a new window or open a new tab. It's also now possible to specify the default font, size and colour of text when composing HTML mail and Mail & Newsgroups now has support for CRAM-MD5 authentication. Image blocking and disabling is now more flexible, allowing you to optionally view images that have not been loaded, and the 'Launch File' button in the download dialogue or Download Manager now works after downloading an executable. Proxy auto-config failover has also been implemented and Mozilla can now be built using GCC on Windows. Read the Mozilla 1.4 Beta Release Notes for more information and download the new version from the mozilla.org Releases page or the mozilla1.4b directory on mozilla.org's FTP site.

I see this bug: http://bugzilla.mozilla.org/show_bug.cgi?id=131456
Seems to have been more or less fixed for 1.3, but then regressed in 1.4 alpha. If you look at the last two comments it seems to indicate there are still memory leaks.

Why is XFT not built into the standard binaries? I should be able to download a nightly build and have anti-aliased fonts. XFT is pretty standard in X, but not for Mozilla yet? That seems pretty hokey to me.

Because up until 1.4b it was incredibly buggy? For example, almost all non-English text had issues with rendering. I _think_ this is fixed. If 1.4b is better, perhaps we can try to build XFT by default in 1.5a. Of course if having half the text on the page not show up is a good thing, we should have been building XFT in all along....

Also, there is currently no way that I know of to turn off the XFT rendering in XFT builds; since XFT is ridiculously slow (an order of magnitude slower than normal rendering at least) over remote X connections with no RENDER extension there needs to be a way to turn it off if we make this the default -- the alternative is to make Mozilla completely unusable on anything that's not a desktop Linux machine (eg on X terminals).

Finally, Mozilla runs on a rather wide range of Linux systems, many of which do not have XFT. We can drop support for these, of course, but that requires some thinking before it's decided on. Not sure how much of an issue this is now that we've moved to requiring glibc 2.2.

I don't know a whole lot about XFT but would it be possible to detect whether or not the session is XFT capable at runtime? Or even just add a switch when running mozilla --xft or something? Or is adding XFT support an "all or nothing" thing?

Xft is similar speed to normal font rendering over network links if you turn off the antialiasing. With AA turned off, Xft doesn't need to transfer the background image to the client before compositing when the server doesn't support RENDER. If you are going to make comparisons, make sure you do a fair one. Also note that fontconfig/Xft won't need to transfer the glyph metrics from the server for the fonts it uses, which is a big win with unicode or asian fonts.

To speed things up further, the GTK maintainer was suggesting the addition of an API so that applications that knew what they were doing could hook the background transfer. Since most apps or toolkits know what they are going to draw onto (usually because they have painted it white or grey just beforehand), they don't need to ask the server for the background a lot of the time. This substantially increases AA rendering speed for servers without RENDER.

That was a comparison of "Mozilla build with XFT support" vs "'normal' Mozilla build". I know XFT can be faster if told to be so, but as long as the XFT Mozilla builds don't tell it so the point is moot.

It looks like all images for any site with a port number specified (http://site.com:1234/etc) automatically have images blocked from until I specify "Unblock images from this site".
Anybody else seeing this?

BTW I have to agree with 'leet' that it is **utterly bizarre** MozillaZine didn't actually post a proper news item about the branding policy/backdown way back when it came out. (Maybe it's being spun differently but that's what it was.) Is this a breakdown of news integrity on the site? If so, I don't really understand it, as there were posts on all *previous* developments in the controversy. If it was just an oversight, I don't really understand it either, as it's basically the end of the main story that had dominated the site for a week or so. (Yeah they linked to the branding policy a couple times, but no news item saying what it said...)

I think it's a good thing, although I think the Firebird SQL bastards also need a good kicking for their ridiculous gamesmanship, self-promotion, and claim to ownership of a widely used name - I thought that was the way huge evil companies (like AOL) behaved, not little (and, evidently, evil) open-source projects. Roll on MySQL, that's what I say, and I hope I never hear of 'FirebirdSQL' again...

But anyway, the firebird name sucked so I'm glad it's gone, except as a codename. And the mozilla name's good so I'm glad it's here to stay.

"BTW I have to agree with 'leet' that it is **utterly bizarre** MozillaZine didn't actually post a proper news item about the branding policy/backdown way back when it came out. (Maybe it's being spun differently but that's what it was.)"

There was an article about the policy the day after it was published: http://www.mozillazine.org/talkback.html?article=3110

If you mean the whole mozilla.org backdown/victory for the Firebird database people, that exists entirely in the head of Paul Festa: http://news.com.com/2100-1032_3-1000146.html

There probably will be an article about the News.com report but we're trying to get a more concrete idea of mozilla.org's real position (something you'll note was conspiciously missing from the News.com article) before publishing it.

"Then you should probably stop trolling Mozillazine looking for attention. That would be my suggestion to never hearing of Mozilla Firebird again."

You can call me a troll until Windows becomes stable and Mozilla will still be as corrupt as Microsoft. Some roach may eliminate me from MozillaZine, or I may leave on my own, but Mozilla will still be corrupt. I do not have to look for attention. Attention looks for me. If you took the time to read my posts, you might realize I am right. Mozilla could be a more popular browser if the developers considered Mozilla's criticism rather than attempting to silence it.

I'm having the following problem with both 1.4b and 1.3.1. 1.3 doesn't have this problem.

Everytime I start Mozilla my McAfee Firewall (3.02) it says the application has changed since it was last run and asks me if I want it to access the internet. When I tell it to fully allow access it then says Mozilla is trying to use 'outbound TCP port xxxx' and I have to allow that as well. If I then close Mozilla and start it again it goes through the same process.

One thing I have noticed is that the port number Mozilla is using keeps changing (1034, 1134, 1140, 1161 & 1165 to name just a few).

I noticed it when I installed 1.4b, I then decided to try 1.3.1 and that behaved the same. I went back to 1.3 which doesn't have the problem.