MOZILLA_1_2_RELEASE is missing some checkins from MOZILLA_1_2_BRANCH



17 years ago
8 years ago


(Reporter: malcolm-bmo, Assigned: leaf)


Other Branch

Firefox Tracking Flags

(Not tracked)



(1 attachment)



17 years ago
Fixes for at least the following bugs were made into MOZILLA_1_2_BRANCH, but 
have 'disappeared' from MOZILLA_1_2_RELEASE.  That is, these bugs were thought 
to have been fixed in 1.2, but the 1.2 release tag does not include the fixed 
versions, though the 1.2 branch tip does.

Bug 178722: calling Array.sort() on an empty array returns undefined instead of 
an empty array
[venkman fix only]

Bug 124556: Crashing on random pages in 8-bit StaticGray class X11 server
[bug is critical, crash]

Bug 180339: Can't send message if receiver contain Chinese character

Bug 167663: [OS X]window disappears when clicking the maximize button (green +)
[checkin similar to third attachment, but not identical]

Bug 173195: Changes in the Mozilla/Netscape Installer to run Palm Conduit 

Were the binaries made against MOZILLA_1_2_RELEASE?


17 years ago
Version: Trunk → Other Branch

Comment 1

17 years ago
All the changes between MOZILLA_1_2_RELEASE and the tip of MOZILLA_1_2_BRANCH.

Comment 2

17 years ago
More details (for that bug only) are available at bug 124556 comment 16 and 

Comment 3

17 years ago
Interesting to note that none of the bugs mentioned appear on the "make Mozilla
1.2 not suck" bug dependency list

Bug #167663 was removed from the dependency list on 11/20. The others don't
appear to have ever been on the dependency list.

Comment 4

17 years ago
Not all the checkins for 1.2final appeared on the '1.2 not suck' list.

Bug 167663 was removed from the list because a more complete fix was expected 
on the trunk.  See bug 167663 comment 108.

Comment 5

17 years ago
Apropos missing stuff: bug 182550 - Talkback is missing on 1.2 release, Linux
(not explicitly mentioned in the diff)
For the record, I'd think this probably doesn't affect the release builds, since
the (major-platform, anyway) release builds are done from the branch before the
release is tagged (and then tested to see if they're working correctly before
they're considered the release). (Or has someone tested that it does?)

Comment 7

17 years ago
I have pulled MOZILLA_1_2_BRANCH from CVS yesterday as I have documented
at  (README file)

The source code obtained is in the tarball mozilla-1.2-branch.source.tar.bz2
at the URL above.

recursive diff with the MOZILLA_1_2_RELEASE as posted on
gives me about the same as attachment 107704 [details] on this bug

I checked the source code manually; bug 124556 is correctly fixed,
and bug 167493 is correctly backed out, i.e. the TagList starts with an "8"
instead of a "9", cf attachment 98435 [details] [diff] [review]

I've produced a build on Solaris8 (my 4th in 3 days I think :-)
and the result is another mozilla-1.2.sparc-sun-solaris2.8.tar.bz2
posted above.

This build passes basic QA for me :-)
ie it doesn't crash due to patch for 124556 missing,
and I cannot reproduce parser bugs due to bug 167493 tracked in bug 182500
for instance bug 182498 is fixed and attachment 107701 [details] displays the
anchor/link correctly, as expected.

Do we need anything else to ship this as 1.2.1 ?

Comment 8

17 years ago
I'd like to publically thank (or as publically as I can on bugzilla) those who
worked hard to determine the problem with 1.2, and to endico and asa for the
Official Mozilla statement on the problem and for pulling access to 1.2. This
quick reaction is yet another example of customer service that one would never
see from Microsoft and its IE product. And just think, MS staff are paid to
provide service, while Mozilla people aren't (well, some are, but the vast
majority aren't).

Also nice to see all the compliments posted at Mozillazine.

Comment 9

17 years ago
dbaron points out that the user agent is getting revved on the 1.2 branch... so
you might need to rebuild your solaris build.

(also, the binaries are produced just before the tag is made... but it's
possible the tree used for tagging was a few revisions behind).

The 1.2.1 tag/source will not have this issue.
Assignee: seawood → leaf

Comment 10

17 years ago
Ok the original 1.2 release tag is fixed (not including the dbaron fix). Fixing
source tarfiles now while we wait for 1.2.1 builds to test.
Closed: 17 years ago
Resolution: --- → FIXED

Comment 11

17 years ago
*** Bug 182550 has been marked as a duplicate of this bug. ***

Comment 12

17 years ago
Urk, dont you people want to reconsider in future just changing tarballs ?

Comment 13

17 years ago
We'd like to get the tags, source tarfiles, and binaries to match up. The
binaries had the code, there was no way to re-release those. Tag and source tar
files have been fixed.

updated tarfiles posted 2002/12/1

Comment 14

17 years ago
Just pulled MOZILLA_1_2_1_RELEASE from cvs -- tarball now available off

Looks ok so far, only changes with the MOZILLA_1_2_BRANCH source tarball
posted above are:

-       <string>0.9.7+, <C2><A9> 1998-2002 The Mozilla Organization</string>
+       <string>1.2.1, <C2><A9> 1998-2002 The Mozilla Organization</string>
-       <string>0.9.7+</string>
+       <string>1.2.1</string>
-       <string>1.2, <C2><A9> 1998-2002 The Mozilla Organization</string>
+       <string>1.2.1, <C2><A9> 1998-2002 The Mozilla Organization</string>
-       <string>1.2, <C2><A9>1998-2002 The Mozilla Organization</string>
+       <string>1.2.1, <C2><A9>1998-2002 The Mozilla Organization</string>
-       <string>1.2</string>
+       <string>1.2.1</string>
-       <string>1.2</string>
+       <string>1.2.1</string>
-#define                VERSION_MINOR                   0x20    // revision & fi
x in BCD
+#define                VERSION_MINOR                   0x21    // revision & fi
x in BCD
-#define                VERSION_STRING                  "1.2"
+#define                VERSION_STRING                  "1.2.1"
-        0x20,
+        0x21,
-        "1.2",         // short version string
-        "Mozilla 1.2 Installer"        // long version string
+        "1.2.1",               // short version string
+        "Mozilla 1.2.1 Installer"      // long version string

Checking source code manually:
bug 124556 is correctly fixed per attachment 106427 [details] [diff] [review],
and bug 167493 is correctly backed out, i.e. the TagList starts with an "8"
instead of a "9", per attachment 98435 [details] [diff] [review] ...

Building now...

Comment 15

17 years ago
Followup on comment 14 above, doing QA the same way as comment 7:

Build of MOZILLA_1_2_1_RELEASE doesn't crash due to patch for bug 124556 missing,
and I cannot reproduce parser bugs due to bug 167493 tracked in bug 182500
for instance bug 182498 is fixed and attachment 107701 [details] displays the
anchor/link correctly, as expected.

However, my Solaris build displays in HELP | ABOUT:

Mozilla 1.2
Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.2) Gecko/20021203

In other words, the ABOUT section or User-Agent doesn't display the fact
it's version 1.2.1 on Unix (unlike the Win32 version, which displays it

Can anyone verify that other Unix builds have the same problem ?
(Linux, anyone ?)

In other words, what I built now on Solaris looks indistinguishible
from the build of the tip of MOZILLA_1_2_BRANCH from comment 7

I'm fairly sure I didn't screwup mixing the sources: a quick glance at
mozilla/configure states MOZILLA_VERSION='1.2.1'

Comment 16

17 years ago
Nicolas: I see the correct version number in about: - using the Linux .tar.gz

Comment 17

17 years ago
It has been a long day and I almost thought I was going nuts, and despite the
fact that I cannot pull MOZILLA_1_2_1_RELEASE from CVS right now as is hosed -- it doesn't even respond to "cvs login"...

I started mozilla on a non-existing profile, selected HELP | ABOUT then quit.
Here are the generated contents of $HOME/.mozilla/default/xxx.slt/prefs.js :

# Mozilla User Preferences
// This is a generated file!

user_pref("browser.startup.homepage_override.mstone", "rv:1.2");
user_pref("prefs.converted-to-utf8", true);
user_pref("timebomb.first_launch_time", "1038948651011347");

I'd be curious to find out what the "override mstone" above is for :-)

Also, every time I delete it and start mozilla, it gets added back...

could that be the culprit for making a 1.2.1 version look like a 1.2
in the HELP | ABOUT MOZILLA page (and possibly, the User-Agent ?)

Comment 18

17 years ago
Nicolas: Do you still get the worng User Agent if you visit one or two different
pages before going to "Help > About Mozilla"? This looks to get only set for the
startup override homepage (The first page that is shown for a given profile with
that version).
I'm also seeing rv:1.2 on the RedHat 8 xft-enabled RPM builds.

Comment 20

17 years ago
The RedHat 8 xft build has been contributed (not built by
like the Solaris build I am doing.

Could it be that every contributed build, issued from a cvs checkout of
the MOZILLA_1_2_1_RELEASE as per the official instructions,
displays a rv:1.2,

whereas the "official" builds display rv:1.2.1
for instance because they were not make according to the "official instructions"
but the builds were made against the tip of the MOZILLA_1_2_BRANCH ?

Comment 21

17 years ago
PS: that would mean that MOZILLA_1_2_1_RELEASE is still missing some
checkins from the MOZILLA_1_2_BRANCH !

Comment 22

17 years ago
Found it... the above is true, MOZILLA_1_2_1_RELEASE still doesn't correspond
to the tip of MOZILLA_1_2_BRANCH and is missing some checkins, specifically
attachment 107815 [details] [diff] [review] of bug 182812
is correctly checked in MOZILLA_1_2_BRANCH but partially into

Details of what's different between MOZILLA_1_2_BRANCH

--- MOZILLA_1_2_1_RELEASE/mozilla/modules/libpref/src/init/all.js Wed Nov 13
17:07:23 2002
+++ MOZILLA_1_2_BRANCH/mozilla/modules/libpref/src/init/all.js      Sat Nov 30
11:59:48 2002
@@ -47,7 +47,7 @@
 pref("keyword.enabled", false);
 pref("general.useragent.locale", "chrome://navigator/locale/");
-pref("general.useragent.misc", "rv:1.2");
+pref("general.useragent.misc", "rv:1.2.1");

 pref("general.startup.browser",             true);
 pref("general.startup.mail",                false);

In other words, MOZILLA_1_2_1_RELEASE has
  pref("general.useragent.misc", "rv:1.2");

while MOZILLA_1_2_BRANCH has
  pref("general.useragent.misc", "rv:1.2.1");

So are the _RELEASE tags hopelessly hosed ?
It looks like the only way for contributors to produce correct builds
is once again to checkout via CVS the tip of the _BRANCH
(which is what is doing, and that explains why only
the official builds display the correct version, rv:1.2.1 !!!)

Comment 23

17 years ago
mozilla-source-1.2.1.tar.bz2 available at

contains the wrong User-Agent rv: and needs to be pulled.
It matches MOZILLA_1_2_1_RELEASE/mozilla/modules/libpref/src/init/all.js with
  pref("general.useragent.misc", "rv:1.2");

(the "src" directory and contributed builds are the only things that
were built against MOZILLA_1_2_1_RELEASE apparently)

Comment 24

17 years ago
The correct source code tarball of what should be MOZILLA_1_2_1_RELEASE
is now posted at

(file mozilla-1.2_BRANCH.src.tar.bz2)

The included file mozilla/modules/libpref/src/init/all.js has the correct
  pref("general.useragent.misc", "rv:1.2.1");

Comment 25

17 years ago
Building this sources (my 7th build!) produces a Solaris8 distribution
of Mozilla 1.2.1 that passes finally my stringent QA process
(comment 15 above)

Updated README and binary distribution posted on
until Dawn pushes them on

All contributed builds on and src/ distributions
are currently invalid and will display rv:1.2.1 instead of rv:1.2

Hopefully this should be the end of this saga...

Comment 26

17 years ago
The above should read:
  ...and will display rv:1.2 instead of rv:1.2.1

Maybe people triaging bugs reported on rv:1.2
should be made aware that the User-Agent string is not reliable
for this revision of the Mozilla client.
verified per final comments

Comment 28

17 years ago
err... not really, if you read the last comments
the MOZILLA_1_2_1_RELEASE tag was just missing the
rv: patch to increase version to 1.2.1
and nobody ever confirmed this was fixed...

is it?
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.