Slashdot Mirror
Mozilla 1.2.1 Released
I shouldn't be allowed to work before coffee- I posted this at like 8:20 and must've forgotten to click that all important 'Save' button. Hey, Everyone's favorite web browser besides Chimera has released version 1.2.1. The fix includes security patches so it probably wouldn't hurt to snag it if you're running it.
Since the story didn't mention it, the only difference between 1.2 and 1.2.1 is the fix for the DHTML bug (#182500).
From the release notes: "The only difference between the two releases [1.2 vs 1.2.1] is the fix for this bug (Bug 182500)." And it was a DHTML bug, not a security bug. -- Andrés
dynamic HTML
Dynamic HTML is a collective term for a combination of new Hypertext Markup Language (HTML) tags and options, that will let you create Web pages more animated and more responsive to user interaction than previous versions of HTML. Much of dynamic HTML is specified in HTML 4.0. Simple examples of dynamic HTML pages would include (1) having the color of a text heading change when a user passes a mouse over it or (2) allowing a user to "drag and drop" an image to another place on a Web page. Dynamic HTML can allow Web documents to look and act like desktop applications or multimedia productions.
The features that constitute dynamic HTML are included in Netscape Communications' latest Web browser, Navigator 4.0 (part of Netscape's Communicator suite), and by Microsoft's browser, Internet Explorer 4.0. While HTML 4.0 is supported by both Netscape and Microsoft browsers, some additional capabilities are supported by only one of the browsers. The biggest obstacle to the use of dynamic HTML is that, since many users are still using older browsers, a Web site must create two versions of each site and serve the pages appropriate to each user's browser version.
The Concepts and Features in Dynamic HTML
Both Netscape and Microsoft support:
* An object-oriented view of a Web page and its elements
* Cascading style sheets and the layering of content
* Programming that can address all or most page elements
* Dynamic fonts
From one of the bug dependencies at bugzilla...
:test1<br>
:test1'
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2) Gecko/20021126
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2) Gecko/20021126
If an input filed with type set to hidden is not preceded by either the body
open tag or text it will be displayed as a text field, but will not have it's
default value set.
Reproducible: Always
Steps to Reproduce:
1. Save the following in a file:
<html>
<form action="/listings/update.php" method=post>
<input type=hidden name=test1 value=value1>
test2: <input type=hidden name=test2 value=value2><br>
</table>
</form>
</html>
2. Load the file in Mozilla
Actual Results:
An empty text input field apears before the test '
Expected Results:
the field should have been hidden and kept its value.
Workarounds are trivial, the <body> tag or any text, even a period, prior to the
hidden input will cause it to behave normaly.
There was no "permissions bug" on Unix. It worked just fine for my non-root user ID.
In this case, Mozilla ate the first characters of a print() function. Many ads are constructed using print() statements, and if the first characters are lost, you don't get to see the advertisement (which could be good), but you also end up with strange html (which is bad).
Teenagers these days don't have as much sex as they want each other to think they do.
Actually, the headline isn't completely wrong, Mozilla 1.2.1 only contains the "can't write to dynamically created elements" fix that was breaking some DHTML and page layout. Mozilla 1.2.1 also contains everything that the 1.2 release contained when it was released and then unreleased last week. That included new features, improved performance, better stability and security fixes. So if you're using _any_ oler Mozilla releases you really should upgrade to get all the new 1.2.1 goodness, including improved security.
For the folks that just downloaded Mozilla 1.2 last week, if you're not having any problems (and it seems like the DHTML issue is a lot less visible on linux) then there's no pressing "security" reason to upgrade to 1.2.1 but you might as well get it for this DHTML fix which is likely to eventually cause you some pain at some site somewhere.
--Asa
Just grab the Talkback-enabled ZIP file, skip the installer altogether.
How come the solaris releases are always days or even weeks behind?
mozilla.org makes binaries for Mac9, OSX, Linux, and Windows. All other builds (sometimes as many as a dozen or so platforms) are contributed builds.We release when we've got the four major platforms done and then the Solaris and FreeBSD and OS/2 and BeOS and all the other builds arrive later.
--Asa
(Actually, let me have the original 1.2 final installer back, because at least that one seemed to work, and minor DHTML bugs are something I'll put up with if they let me read the web and my mail at the same time)
No one ever took it from you. If you deleted it after the install just go back to ftp and download it again. I'd recommend that you do an uninstall and remove any traces of the Mozilla install directory then try a reinstall of 1.2.1. There should be no problems with a clean install. If that doesn't work then try creating a new profile and see if that works (you can copy your old profile data over to the new profile if necessary). I'm surprised you're having this difficulty and hope that one of the steps I suggested would fix it. The chances of 1.2.1 introducing a problem that didn't exist for you in 1.2 are about zero so I suspect that some other problem is at work here, possibly cruft left over from a beta install. Like I suggested above, removing the entire beta install directory should clear up any problems if it was a beta build problem that's manifesting in the final release. Good luck.
--Asa
Was the fix that involved?
:-)
To my (faint) understanding: Maybe
Looking at the bug page of bug #182500 on bugzilla.mozilla.org (sorry, direct links blocked from slashdot), the list of associated bugs has 32 entries, and is a result of an incorrect backout of way too much code at some point just before the 1.2 release.
Somebody closer to the mozilla project could surely give more detailed / accurate info on this though.
Yes, there was a permissions bug. Bug 163524 would mess up the permissions in the components directory if a earlier version had been installed. This would cause any non-root user to not be able to run mozilla, at all. Most distributions come standard with mozilla, so it's very hard to get a installation without it... making the release a hurdle for practically everyone.
"And we have seen and do testify that the Father sent the Son to be the Savior of the World"
1 John 4:14
The problem that I'm running into here is that the installer segfaults while it's trying to install the EN-US language pack. Anyone else have any idea what's going on here?
"The best argument against democracy is a five minute chat with the average voter."
--Winston Churchill
There is an excellent browser toolbar for mozilla which emulates the googlebar at;
http://googlebar.mozdev.org/
This seems to be having problems with the Linux build at present but two other projects linked from this page are Mycroft which has plug ins to allow you to search over 170 different search engines (check it out) and Easysearch which allows you to search google and others.
While exploring the mozdev site, check out Mouse Gestures, Pie Menus (both under Optimoz) and the Multizilla toolbar. These, for me, have made browsing fun and efficient once again.
If you are keen, there is an easy to follow tutorial on building your own toolbars at;
Building a toolbar for Netscape 7 (applies to Mozilla too). I used this to write a toolbar to search our Corporate Directory, Intranet and Google, It took me three days to write from scratch but is now quite widely used.
The fix to bug 182500 was a single character. An 9 was changed to an 8. There was not a backout of way too much code.
The problem was that a checkin that added a value to an array was incorrectly backed out. The size of the array was written explicitly instead of using sizeof and preprocessor magic, and the change to the size wasn't backed out along with the value added to the end of the array. The incorrect size caused whatever random data was stored after the end of the array to be read. (The array was in the HTML parser, containing a list of the types of things that are valid children of the HEAD element. Thus, I think the bugs can be traced to things that should have been in the BODY ending up in the HEAD.) Depending on the compiler, this caused different behavior, so the bug was worse on Windows (with MSVC 6.0) or on gcc 3.2 (on x86 Linux) than it was with egcs 1.1.2 (on x86 Linux).
So, in other words, the size of the binaries shouldn't have changed. That's odd.