Slashdot Mirror
Mozilla 1.4b Loosed
An anonymous reader writes "The fine Mozilla folks have decided to bless us with the release of Mozilla 1.4b this weekend. Highlights include support for NTLM authentication, usability improvements, and lots of performance, stability, and site compatibility fixes. As always, the release notes have more detailed info on changes."
Mozilla 1.3.1 (bugfix update for 1.3) was released this week, too.
Google doesn't index user sigs, so stop trying to "Google Bomb" with them.
ftp://ftp.mozilla.org/pub/phoenix/nightly/latest-t runk
Also check out all of the extensions, most of which still work on the latest nightly build.
Mozilla 1.4a is "alpha" (hence the "a"). Likewise, Mozilla 1.4b, the version being mentioned in this article, is "beta" (hence the "b"). Once Mozilla 1.4 is finished, it will be released as simply "Mozilla 1.4" and that'll mean it's stable.
Then a few months later some minor bugs will be ironed out (or in a few minutes some major bug will be) and that'll be Mozilla 1.4.1. By that time, Mozilla 1.5 may very well be starting its own release cycle.
Mozilla 1.4b Loosed
Good lord, when you people learn, it's LOSE, not LOOSE! LOOSE means to "let loose, to free, to release", and LOSE mea...
Erm.
Never mind. You got it right this time. Carry on then.
Actually, that could be a good thing. It may lead to a deployment of Mozilla within an organization that has resources secured by MS server packages (IIS, SQL Server, etc).
In my opinion this shows the Mozilla team being a bit more agressive in making inroads into the corporate (sometimes MS-dominated) world. Good for them.
Wearing pants should always be optional.
Definitely! I love tabbed browsing, and the popup and cookie features are far superior to IE. Mozilla has become my primary browser. I've been investigating the calendar feature too. I plan on proposing that we implement it company-wide at my work. Mozilla has matured greatly and it's only getting better. You should check it out again.
I have an idea for image blocking. Now that Mozilla uses a statistical technique to identify spam, presumable with some sort of set of words to begin the database before it is trained with our spam messages, perhaps we could apply some sort of guessing technique for image blocking.
A central database of crap ( read Doubleclick.net ) images could be maintained. Images could be checked against the database and then blocked or allowed based on that. Perhaps the domain that the images come from could be taken into account as well.
Wh47 d1d j00 541, 31337 15n't t3h r0xor5 ne m0r3???
Many people will consider NTLM support as superfluous pro-MS bloatware and another useless addition to Mozilla.
:)
I'd like to point out this is just plain wrong. There are many developers that are forced to use IE to do their job just because the company's product runs on IIS and uses NTLM.
Mozilla supporting NTLM means better ways of testing software for these developers, as well as giving a better idea of the web homogeneity of the product.
Free myself from IE at work ! Go for NTLM, Mozilla !
Karma cannot be described by words alone.
Check out the NTLM authorization proxy server here.
That's what I use.
And the beast shall be made legion. Its numbers shall be increased a thousand thousand fold. The din of a million keyboards like unto a great storm shall cover the earth, and the followers of Mammon shall tremble.
from The Book of Mozilla, 3:31
(Red Letter Edition)
Why, o why must the sky fall when I've learned to fly?
This is actually a great thing. I frequently work with clients who run IIS on their intranets. As it stands now I have no choice but to switch to IE when accessing areas that use NTLM authentication. This is one less reason for me to fire-up IE.
Ultimately this could contribute to a wider deployment of Mozilla in corporate environments.
Add a link to firebird in your start-up folder, with "-turbo". It will then rest in your toolbar. When you go to launce firebird for real, the window will come up much quicker.
Ryan
Thanks, Mozilla installer team! You have successfully produced an installer that prevents me from ircing while Mozilla installs!
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
SVG support is still very much incomplete; the browser won't recognise SVG that is embedded into pages using the embed tag (which is pretty much all SVG on the net, since that's what the Adobe plugin supports best). It also doesn't have support for the entire spec, although for basic static graphics, it is pretty much there. The libart licensing issue to which you allude is a simple incompatibility between the MPL/LGPL/GPL trilicense that Mozilla is released under and the LGPL of the libart library. That pretty much prevents mozilla including SVG by default at the moment. In addition, a lot of the SVG had a rewrite quite recently and, because no one has had time to review thousands of lines of new code, it's still living on a branch. That's important if you decide to compile Mozilla with --enable-svg set - to get the new code you need to pull the branch from CVS, otherwise you'll get the older, somewhat buggier code. For more details, including quite detailed build instructions, see http://www.mozilla.org/projects/svg/ If you think that duplicating cpu effort by compiling everything yourself is a waste of time, then there are regular svg-enabled builds contributed to ftp://ftp.mozilla.org/pub/mozilla/nightly/latest These come in two flavors, GDI+ (windows only) and Libart (Linux and windows). All svg builds have mathml-svg in the filename. If you're not on one of those platforms or want something cool like Xft and SVG, you'll need to complie yourself, I'm afraid. For more information, see the netscape.public.mozilla.svg newsgroup.
Comment removed based on user account deletion
Secured?
Don't ever use that word again when talking about a MS server product...
-twb
Mozilla 1.4 beta includes a security fix to prevent web pages from loading XBL from file: URLs (bug 200691, fixed). Unfortunately, the fix also prevents user style sheets from making web pages load XBL files from file: URLs (bug 204140), which affects some users of my XBL Flash blocker (blocks Flash using a placeholder that you can click to play a particular Flash animation).
If you saved flash.xml to disk and used a file: URL for flash.xml in userContent.css, you need to change userContent.css to load flash.xml from a local web server or from the original location on www.cs.hmc.edu instead. Otherwise, Flash won't appear at all (not even a click-to-play placeholder), and you'll see this if you open the JavaScript Console:
"Security Error: Content at http://www.shockwave.com/sw/home/ [or another URL with Flash] may not load or link to file:///C:/.../flash.xml#obj."
The shareholder is always right.
Agreed! And there is a great improvement in these features that I have just noticed in 1.4b and I never saw in 1.4a. There is a little icon in the corner next to the 'lock' that appears if the site uses cookies or popups. Obviously I have popups disabled, so when I see the little popup icon, I get this lovely warm feeling inside knowing that at least 1 pop-up was annihilated. It's so much more gratifying than seeing nothing at all.
Furthermore, you can click on that little icon and change the cookie or popup blocking customisations for that particular site. This way, if a useful popup was identified as 'unrequested' then you know it was killed and you can easily re-enable it.
> Standard HTTP authentication is hideously broken. It's plain text. Period. That's all there is to it. It's goddamn plain text.
Bogus. See RFC 2617 section #3, which outlines Digest (MD5) authentication. Digest auth is far superior to NTLM auth because it uses stronger crypto. The only reason to support NTLM is for compatibility with older microsoft products.
Darin