Closed Bug 224340 Opened 17 years ago Closed 17 years ago

v1.6a is missing PSM module: SSL protocols like HttpS, Pop3/Ssl, ... are unavailable

Categories

(SeaMonkey :: Build Config, defect, blocker)

Product:
SeaMonkey
Component:
Build Config
Platform:
x86
Windows 98
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: hhschwab, Assigned: leaf)

References

(
URL
)

Details

(Keywords: regression) 

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6a) Gecko/20031030
Build ID: 2003103019
Using Mozilla Mailclient, I can´t access my account at myrealbox.com
Same account accessed via browser gives an Alert: you must install PSM ...
Same with another account accesses with an https:\\ URL, I get the alert before
anything is loaded.

reproducable: always

Did a clean install, after download installed into a new directory, created a
new profile, didn´t config at all, or load extensions, surfed a bit, ok.
Then I switched to my default profile and tried to access my webmail, got the alert.
Closed 1.6a release, started 1.6a trunk with same default profile, and could
access my mail.
Closed 1.6a trunk, started 1.6a release with its own new untouched profile,
tried to access my webmail by pasting the https: URL into the location bar, and
got same alert.
When I started the mail client, I got the message I´m currently offline, though
DUN was up, and I was asked to allow going online. I accepted, and could access
my POP3-account (non-secure). My secure IMAP-account was spinning, I aborted
about a minute later, didn´t want to wait for an alert.

Install log didn´t differ between Trunk and Release, on a quick view.
At least I didn´t see a message about corrupt or missing files.
Didn´t compare 1:1 if all files were mentioned in both logs.

Raising severity to critical, as this is a release, and maybe couldbe fixed,
as the lacking of https: makes the thing unusable.
You don't need to write books as comment :-)
The PSM installed warning from Necko and missing SSL Tabs in the preferences is
enough information to be sure that that PSM is missing.

I can confirm this on win2k and this file :
http://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.6a/mozilla-win32-1.6a-installer.exe
Severity: critical → blocker
1.5b configure switches (about:buildconfig):
--without-system-jpg --without-system-zlib --with-extensions=all
--enable-optimize --disable-debug --disable-tests --enable-crypto

1.6a :
--disable-debug --enable-optimize --disable-tests

1.5 configure arguments agree with the 1.5b arguments.
This error appears to occur on submission to an encrypted (https) page. An alert
appears informing you of the missing PSM module and instructing you to reinstall
it. My installation was on Windows XP.
*** Bug 224386 has been marked as a duplicate of this bug. ***
Time to "remove" the v1.6a ! Then release a v1.6a.1 ?
At least, add a warning on the v1.6a release note !!


[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6a) Gecko/20031025] (nightly) (W98SE)

If I remember well, this bug did not yet exist in v20031025(04)...

(The change may have happened along the one causing bug 224370 !?)


[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007] (W98SE)

Works fine, confirming comment 3: (K) regression.
Flags: blocking1.6b?
Keywords: regression
Summary: Mozilla 1.6a is missing PSM module, can´t access my mail via HTTPS → v1.6a is missing PSM module: SSL protocols like HttpS, Pop3/Ssl, ... are unavailable
no need for another point release, since the source hasn't changed. I've done a
respin and staged bits, using the configuration options that were used for 1.5.

The bits are starting to hit ftp... if someone with an existing 1.6a install can
test installing the bits from today (november 1), to see if mozilla's installer
will even perform another installation over the top.

If not, i'm sure uninstalling and reinstalling will work. (too bad crypto
doesn't have its own xpi anymore!)
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
*** Bug 224372 has been marked as a duplicate of this bug. ***
Flags: blocking1.6b?
The new build has been apperently build without BUILD_OFFICIAL flag and
therefore shows Build ID: 0000000000.

However this time it has the PSM.

I wonder about this total screw-up: Why weren't any nightly builds available on
October 29 and 30? The latter should be used as the release after testing it for
a day or two. Was this because of the ugly license scattered with with black
rectangles that was added in the last minute?

A real shame for us all :-(
*** Bug 224402 has been marked as a duplicate of this bug. ***
[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6a) Gecko/20031030] (BuildId=0...0,
bug 224340#c9) (W98SE)

Re comment 7:

New build works fine after uninstal+reinstal.
(I did not try the "over-instal".)

Re comment 9:

License format issue: see bug 224370.
(No explanation so far on how theses two bugs came in...)

the source may not have changed, but most mozilla users don't care about that -
what they see changing is the build, and that has changed.

By now a bunch of people have downloaded 1.6a, found it's broken, and gone back
to 1.5. If we want them to test 1.6a, we need to tell them that the version on
the FTP now isn't the broken one they already tried.

Are we just living with the lack of buildID?
Delivering as soon as possible a new build with PSM included was very good :-)

Resolving the bug without in-depth explanation seems premature :-(
"At least, add a warning on the v1.6a release note !!" stands in all cases...
(<http://www.mozilla.org/releases/mozilla1.6a/README.html>)

Full explanation: we're still working through transition issues. Builds used to
be produced by a set of machines running very old and well-tested automation on
the netscape campus. New automation is being written to produce builds now, and
the 1.6a release coincided with a failure of a legacy system, so the first 1.6a
windows builds were produced in an ad-hoc fashion, which resulted in some missed
configuration options (human error). The lack of buildid in the new bits is also
due to human error, in that my haste to produce builds with PSM led me to forget
to set an environment variable to produce official builds. As far as i know, the
lack of buildid is the only effect of this.

I don't have time to produce another set of builds with the OFFICIAL bit set, as
i am going offline until thursday of next week.

I'm not sure what the best way to announce "bits with psm", but updating a
revision number for a build machine configuration issue is not appropriate. An
announcement on the releases page or news item might work. I don't have time at
the present to produce a well worded announcement. If anyone would like to add
criticism to the bug, feel free to do so, and i will read it and respond where
appropriate thursday.

One thing for sure, though, Beta will not have any of these issues.
Leaf: 
I want to say "Thank you" for your Mozilla work and also for the fast fix !
A build without PSM is bad but you fixed that very fast. The missing build ID is
trivial and doesn't affect anything except the Build ID in the title.

Continue your great work and we will be all happy !

Leaf - thanks very much for the explanation and also for the prompt respin (on a
Saturday too). A note somewhere on the releases page or something would be fine,
and I don't think the missing buildID is a significant problem - this is an
alpha, after all.
Status: RESOLVED → VERIFIED
I think i can squeeze in an "official" build before i have to leave. I'll get a
note on the release notes and a brief news item.
New official build is staged (i believe that the license.txt file is correctly
line-ended now as well).

I will post a small news item and send mail to npm.builds. Sorry for the
invonvenience.
The new (2003110115) build has the build ID number back (and thanks to that it
can be called by it, obviously). The license bug is solved too.

You can install the 2003110115 (third try) directly over the 0000000000 (second
try) build with even GRE being replaced thanks to the different build IDs. I
cannot check how it upgrades from the first try build as I already deleted it.

Thanks for fixing the problems during the weekend!
*** Bug 224512 has been marked as a duplicate of this bug. ***
Just for test I installed BuildID 2003110115 right on top of first release Build
ID: 2003103019 and had no problems, still using it.
But seeing now, it gives the wrong UA:
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6a) Gecko/20031030
Re comment 21:

In fact, the UA did not change between the 3 builds ("same sources"):
only the BuildId ("new binaries").

Your test is 100% successful :-)

just deinstalled and reinstalled into a fresh directory, also deleted zonealarm
entries.
ZA asked me to allow Mozilla 2003103019 as server, and the about: page shows
Build ID 2003110115 in the title bar, and Mozilla/5.0 (Windows; U; Win98; en-US;
rv:1.6a) Gecko/20031030 in the content.

That makes it difficult to decide which build is in use, have a look at bug 224589
 Browser crashes when logging on to secure web page via pop-up dialog
Re comment 23:

As I understand it:

"Gecko/20031030" is the date of the Gecko engine only (which was included
in/with this Mozilla build)...
"rv:1.6a" is the only information about which Mozilla "milestone" (not build) it
is... (no BuildId in the User-Agent string.)
"Build ID 2003110115" is the true information to identify a build.

Now, here is what is odd about the third v1.6a build:
*mozilla.exe identifies itself as "1.6a: 2003103019", as ZA reports,
 where we would(!) expect "2003110115".
*the Gecko directory is named "GRE\1.6a_2003110115"
 where we might(?) expect "20031030xx".

That said,
I believe that you were very right to report it, in case there is something to
fix there for the future;
and that, for the v1.6a release, we'll now live with it:
unlike the BID=0...0 of the second build which was kind of a "blocker".

Additional Re comment 23: (for the record)

Bug 224589 is unrelated to the current one.

While looking at it, I wondered about bug 222849 comment 13,
"Build ID 2003110115 (no Talkback packaged)",
but that's bug 218898, unrelated to this one too.

Re: Comment 24

"Gecko/20031030" is the date of the Gecko engine only (which was included
in/with this Mozilla build)..."

No, it is simply the date you put in a file (namely
mozilla/layout/build/gbdate.h) which you want the UA string to show...
*** Bug 224745 has been marked as a duplicate of this bug. ***
*** Bug 224776 has been marked as a duplicate of this bug. ***
Re comment 26:

See bug 150351 comment 17:
{(<http://mozilla.org/build/revised-user-agent-strings.html>)
GeckoVersion: [...] For official Mozilla builds, this will correspond to the
date portion of the BuildID. [...]
}
You're right:
actually, since the third build is an official one (as the second was for that
matter), it should have had the "20031101" date too.

The problem (or is it a feature?) is that if gbdate.h exists, the script
gbdate.pl will not update it. Therefore it is important to remember to delete it
before an official build is done.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.