Mozilla 1.2.1 Coming Soon

Friday November 29th, 2002

Asa Dotzler writes: "We've discovered a bug in Mozilla 1.2 that can cause DHTML on some sites to fail. We've got a fix and will be releasing a 1.2.1 shortly.

"Also, the 1.2 release tag was not complete so builds created from that tag may have additional problems. If you're building Mozilla you can pull the tip of the branch or wait for the 1.2.1 tag to get the correct files.

"Sorry for the inconvenience."

#1 The bug

by asa

Friday November 29th, 2002 4:05 PM

The bug is Bugzilla bug 182500 (please don't link it, that's just creates a lot of unnecessary load on Bugzilla).

"This is a meta-bug whose dependencies will be problems caused by the incorrect backout described in bug 167493 comment 21. Some of these bugs have been reported as Windows-only, but I've also been able to reproduce them on a gcc 3.2.1 Linux build with -O2."

The incorrect backout has been fixed and there's no need for "I'm seeing it too" comments in that bug. Thanks.


#2 Re: The bug

by MozSaidAloha

Friday November 29th, 2002 4:23 PM

The Bug number cited on the releases page ( is wrong. The number cited there is 182450 and not 182500.

#3 Good to hear

by ecarlson

Friday November 29th, 2002 7:46 PM

I've experienced the very obvious "not showing some banner ads" flaw as discussed in the earlier 1.2 thread. Hopefully 1.2.1 will fix that flaw.

- Eric,

#16 Indeed...

by martrootamm

Saturday November 30th, 2002 1:21 PM

Why, of course it's nice when banner ads are not shown :). Just that they are not they only ones using that <ABBR LANG=EN TITLE="Dynamic HTML">DHTML</ABBR> technology... But I can't name anything using that function.

#17 Re: Indeed...

by martrootamm

Saturday November 30th, 2002 1:22 PM

Äh! Can't write in HTML... Lucky me, I have membership in evolt :)

#4 I have problems with PNG

by retype

Friday November 29th, 2002 9:01 PM

I don't know if there is really a bug in mozilla but the maps at don't show right in mozilla(1.2) or in phoenix(0.4)

#5 Re: I have problems with PNG

by digitalgimp

Friday November 29th, 2002 9:18 PM

No problem for me on 1.2/Win

#28 Re: I have problems with PNG

by nakedboy

Monday December 2nd, 2002 2:15 PM

retype, could you be experiencing this?

#6 The intensely long hard disc access when closing

by zero0w

Friday November 29th, 2002 10:23 PM

Do you think the intensive long harddrive access when closing Mozilla browser bug be fixed? It's getting annoying.

#8 Re: The intensely long hard disc access when closi

by sconest

Saturday November 30th, 2002 3:17 AM

This one have been fixed some days ago in the nightllies.

#12 Re: The intensely long hard disc access when close

by zero0w

Saturday November 30th, 2002 7:55 AM

You knew the bug number? It will be useful to keep track of it.

#25 Re: Re: The intensely long hard disc access when c

by sconest

Monday December 2nd, 2002 2:09 AM

No, I don't know the bug number. I saw that my windows closed faster and I didn't hear my hard disk spin anymore.

#14 But will the fix be in 1.2.1?

by mesostinky

Saturday November 30th, 2002 9:04 AM

I haven't used 1.2final much at all, but i know some users claimed to have this problem. So I'm wondering was 1.2 affected by this bug and will it be fixed in 1.2.1.

#30 Yes, the hard disc access when closing

by zero0w

Tuesday December 3rd, 2002 1:32 AM

Nah... 1.2.1 does not fix this problem. Try out the latest nightly build. It works for me (2002120221).

#31 Hell annoying

by jonik

Wednesday December 4th, 2002 12:15 PM

Just updated from 1.2b to 1.2.1 on Windows 2000, and I see this too.. Every time I close a Mozilla window, hard disk trashes very intensively for a few seconds..

#7 Oops...

by jesusX

Friday November 29th, 2002 11:23 PM

It sucks when we all drop the ball, but remember, in this community of ours, everyone sure tries to fix the goofs fast. :)

#9 Strange underlining

by jrepin

Saturday November 30th, 2002 6:39 AM

With Mozilla 1.2 I get strange underlining of text when I mouse over it on the page It was OK in previous versions and this didn't happen. In 1.2 the effext is veeery annoying. Will 1.2.1 fix this problem?

#10 Re: Strange underlining

by Balboa

Saturday November 30th, 2002 7:00 AM

It's because they have a hover effect on all A tags - and there's an open target tag to each news story. Closing this tag would solve this - the page doesn't validate at all, so maybe you should give the webmaster a little poke?

#11 Re: Strange Underlining

by unruly

Saturday November 30th, 2002 7:48 AM

It doesn't need to be an open anchor tag, it could also be one with just a title element in it, giving definition to the word that's underlined. I use it sometimes, and MozillaZine does too.

#15 Re: Re: Strange Underlining

by Balboa

Saturday November 30th, 2002 11:24 AM

My point was that the anchor tag has to have a matching end tag. That's what's causing the problem. As it stands, because it's not closed, it encapsulates the following elements.

#13 good to see they are working fast to fix this bug

by wtmcgee

Saturday November 30th, 2002 8:42 AM

it's nice to see the devolpers make a quick move to get the problem fixed, instead of saying "oh well look to the 1.3a release to fix that problem."

kudos, mozilla team!

#29 Re: good to see they are working fast to fix this

by minh

Monday December 2nd, 2002 9:17 PM

Congrats, you've been quoted by

#18 top-voted bugs

by rgpublic

Sunday December 1st, 2002 9:14 AM

I'm following the mozilla project now for a long time and I keep wondering if bugzillas vote feature is pretty much ignored. Look at this list:,bugs.delta_ts%2Cbugs.votes%2Cbugs.delta_ts%2Cbugs.votes%2Cbugs.delta_ts%2Cbugs.votes%2Cbugs.delta_ts%2Cbugs.bug_id Striking that only 2 of the 20 most-wanted bugs are fixed though some of them exist really for a long time. Some bugs are certainly difficult to solve, especially if you want to solve them "the right way". But still no error-page instead of a dialog-box? No media-type-blocking (are any commercial interests lurking here due to Netscapes close relation to this project)? No Delete attachment from message? I'm personally not so interested in solving any of these bugs but the community certainly is. To make my point clear: I don't want to offense anybody, if I wasn't a fan of open source and the Mozilla project in general if wouldn't write here, but: A little bit more listening to end-users would give the community a "warm fuzzy feeling" especially as we all help testing and using Moz everyday. At least after 2 years that some bugs exists some page at should inform us un-knowing end-users why those most-wanted bugs still aren't solved yet. Some of my enthusiasm for this project is destroyed...

#19 Re: top-voted bugs

by asa

Sunday December 1st, 2002 10:32 AM

First, you're wrong about 2 of the most wanted bugs. Your query is too simplistic to actually give the data you want to support your claim. You're looking at current vote totals. That ignores the fact that many now fixed votes don't have all (or even any) of the votes that they once had. Most people don't leave their votes on resolved issues but rather move them to still open ones. If you look at the list of bugs that ever had a lot of votes (but currently might not) then you'll see scores of fixed bugs which (relatively) large numbers of voting people voted for.

Votes aren't ignored but at the same time they're not the deciding factor in what gets fixed. Votes are disproportionately used in feature requests. Should we attempt to move resources to the top voted for feature (because a few hundred people voted for it) and so not fix the top crash in our product (which is impacting tens of thousands of people or more) because it doesn't have a single vote? Should we ignore dataloss in existing features and focus our attention on implementing new features because dataloss bugs don't get a lot of votes and "implement PGP" does?

Not only that but votes don't say as much as you're suggesting about the wants of the end-users. You said "I'm personally not so interested in solving any of these bugs but the community certainly is." That may be correct if by "community" you really mean the few people that vote in Bugzilla. Mozilla had over a million downloads of Mozilla 1.0. That a couple hundred people put a vote on a particular bug or feature request doesn't really say much about the wants of Mozilla end-users. That's what, about 1/50th of 1% of Mozilla 1.0 users that have voiced an opinion. Bugzilla has over 50,000 accounts. Even if you just look at Bugzilla account holders as a representative sample of end-users (I dispute this heavily but for the sake of argument we can discuss it) then you've still got less than 1/2 of 1% of Bugzilla users voting for a particular feature or bugfix (mostly features). These are people that actually registered a Bugzilla account, many of whom commented in or created new bugs and didn't vote for that particular bug. To suggest that "the community" wants something with no more evidence than a couple hundred vocal bugzilla account holders checking a checkbox is a bit simplistic and probably wrong more often than right.

Additionally, there's no mechanism to vote against a pariticular feature and so who is to say that a bug with 200 votes for might not have 300 votes against. Because 200 people said they wanted it is an indication but doesn't necessarily mean that it's wanted by the rest of the Bugzilla or larger Mozilla community. I'd wager that I could file a bug "don't implement PGP" and, given a couple of years and enough highly moderated posts at /. and mozillaZine, get sufficient votes on my bug to get it on your top 20 list. Should we then implement code which makes PGP impossible to implement in Mozilla? I know that's a silly example but for a less silly example imagine I filed a bug "remove Mozilla's HTML Composer program". I'll bet I could get a few hundred votes for that idea pretty easily given all the /. sentiment about bloat. Would that be doing a service to all of the people that use Composer every day?

Even though your query doesn't come close to accurately representing the real state of bugs voted for, and voting is only used by a very vocal minority, is disproportionately asking for new features over bug fixes, doesn't take into account that dissenting votes, and is used so little that it's easy to manipulate with a simple /. or mozillazine campaign, I said above that it's not ignored. And it's not., who work to build the Mozilla Roadmap and manage checkins during release cycles, are watching votes to see what that extremely vocal and very small group of people want and are taking that into consideration when making some decisions.

Voting is useful. If it was used by more people it might be slightly more useful but no matter how you square it, voting is never going to be clearly representative of what the community wants fixed or implemented in Mozilla. It's just a tiny sliver of opinion coming from an extremly tiny minority. use voting but they also use bug nominations, talkback topcrash data, technical dependencies, developer recommendations, newsgroup and other feedback forums, the needs of contributing organizations like Sun, IBM, Netscape, etc., published reviews and many other sources of input in determining where to move emphasis on the project.

That voting isn't the only mechanism may be a disappointment to you and others but that's gonna continue to be a disappointment because voting is unlikely to be come the sole factor in any decision making in this project for a long, long time. If "Some of [your] enthusiasm for this project is destroyed" because of this, that's a shame but that loss of enthusiasm by a few bug voters is not going to stop the developers from continuing to fix problems and make Mozilla better with every passing day.


#20 What's changed...

by dgk

Sunday December 1st, 2002 10:56 AM

Asa, very good answer, a wee bit negative, but a good answer.

Is there a bug filed against Bugzilla to add a "vote against this bug" option? This option would, if nothing else, balance out the "Vote for this bug" option. If there isn't a bug files, let me know and I'll file one.

However, you are right in saying that TOPCRASH and DATALOSS (and, for that matter, the situation with v1.2) should always get higher priority than bugs with the highest vote count.

#22 Re: What's changed...

by Sander

Sunday December 1st, 2002 3:06 PM

>> Is there a bug filed against Bugzilla to add a "vote against this bug" option? <<

bug 48570: - has 30 votes already; wonder how many votes against it would have... ^_^

#23 Re: Re: top-voted bugs

by rgpublic

Sunday December 1st, 2002 3:58 PM

Thanks a lot for your answer. It really gave me a lot of insight. You might even consider including that somewhere on bugzilla's homepage or faq or even better: whenever you vote. That might save a lot of people from overestimating the voting feature. I agree with most of your points. Mozilla has certainly proven to be a stable and secure browser. Germany's #1 computer magazine has even titled "security hazard IE" and a comprehensive introduction how to install and configure Mozilla, in its latest edition. Sometimes I'm afraid though that M$-IE could steal the show again with features more visible to the end-user. But the right mix between "end-user-features" and crash-bug-fixing is certainly difficult. Well, after your post, at least I look a lot more optimistic into the future as my trust in Mozilla's "open source democracy" is restored.

#21 Re: top-voted bugs

by mbokil

Sunday December 1st, 2002 12:10 PM

You point out an important issue with Mozilla I have noticed also; realy old bugs seem to be neglected. The memory leak issues with images should be fixed pronto. A problem that is occuring is that some of the owners of these bugs are no longer working on mozilla and so they just twist in the wind. Developers know they are there but there are not enough qualified people to fix them. Possibly as AOL moves more of the developers over to work on their proprietary AOL Communicator suite this problem will get worse. Any drivers want to comment on this labor issue with Mozilla?

#24 Re: Re: top-voted bugs

by asa

Sunday December 1st, 2002 4:37 PM

"Developers know [bugs] are there but there are not enough qualified people to fix them."

Have we ever had enough qualified people to fix all the bugs that developers know about in the timeframe we'd like? No. Have developers been moving on to other projects (via new jobs or new interests) leaving bugs unfixed since the beginning of the project? Yes. Do I expect either of those trends to change? Not any time soon. Does that prevent Mozilla from getting better all of the time? Nope.

"Possibly as AOL moves more of the developers over to work on their proprietary AOL Communicator suite this problem will get worse."

AOL is moving developers that were contributing to Mozilla over to AOL Communicator? Like who? When?

I'm personally not as concerned with the quantity of developers as I am with the quality of the code going in the tree. has been gaining and losing contributors from the beginning but I think the code quality, especially in key areas, is getting better. All projects have turnover; Mozilla is no exception. With Mozilla this is true of organization and individual contributors. There has always been a shortage of people qualified to work in certain areas of the codebase and, yes, that is true today.

But we've got a lot of great new talent coming into Individuals and massive corporations both. We've also lost some talent. It's nice that we have a number of corporate contributors and lots of individual contributors so that we're not completely dependent on the contributions of any one organization. Some of the most qualified engineers on the project in the more difficult areas aren't Netscape employees and many areas are developed almost completely independently of Netscape. Netscape may currently be the largest employer of developers contributing code to but they are not the only large contributor. Sun, for example has been ramping up development over the last year or so and their team is getting quite large. And there are contributors from RedHat, OEOne, IBM, Worldgate and other corporations as well.

We can always use more developer contributions. If you're concerned about manpower and you or your employer have engineering talent then step up with some code or encourage your employer to step up with resources. I'll be glad to help get you "plugged in" to our process and tools.


#26 Will Mozilla 1.2.1 effect Galeon 1.27

by javaman67

Monday December 2nd, 2002 4:56 AM

I just downloaded Mozilla 1.2 and Galeon 1.27 and everything is working fine. Will the upcoming Mozilla 1.2.1 work with Galeon 1.27 ?

#27 Will Mozilla 1.2.1 effect Galeon 1.27

by javaman67

Monday December 2nd, 2002 4:56 AM

I just downloaded Mozilla 1.2 and Galeon 1.27 and everything is working fine. Will the upcoming Mozilla 1.2.1 work with Galeon 1.27 ?