Closed
Bug 224340
Opened 21 years ago
Closed 21 years ago
v1.6a is missing PSM module: SSL protocols like HttpS, Pop3/Ssl, ... are unavailable
Categories
(SeaMonkey :: Build Config, defect)
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: hhschwab, Assigned: leaf)
References
()
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.
Comment 1•21 years ago
|
||
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
Comment 2•21 years ago
|
||
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.
Comment 4•21 years ago
|
||
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.
Reporter | ||
Comment 5•21 years ago
|
||
*** Bug 224386 has been marked as a duplicate of this bug. ***
Comment 6•21 years ago
|
||
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
Assignee | ||
Comment 7•21 years ago
|
||
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: 21 years ago
Resolution: --- → FIXED
Comment 8•21 years ago
|
||
*** Bug 224372 has been marked as a duplicate of this bug. ***
Updated•21 years ago
|
Flags: blocking1.6b?
Comment 9•21 years ago
|
||
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 :-(
Comment 10•21 years ago
|
||
*** Bug 224402 has been marked as a duplicate of this bug. ***
Comment 11•21 years ago
|
||
[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...)
Comment 12•21 years ago
|
||
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?
Comment 13•21 years ago
|
||
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>)
Assignee | ||
Comment 14•21 years ago
|
||
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.
Comment 15•21 years ago
|
||
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 !
Comment 16•21 years ago
|
||
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
Assignee | ||
Comment 17•21 years ago
|
||
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.
Assignee | ||
Comment 18•21 years ago
|
||
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.
Comment 19•21 years ago
|
||
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!
Comment 20•21 years ago
|
||
*** Bug 224512 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 21•21 years ago
|
||
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
Comment 22•21 years ago
|
||
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 :-)
Reporter | ||
Comment 23•21 years ago
|
||
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
Comment 24•21 years ago
|
||
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".
Comment 25•21 years ago
|
||
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.
Comment 26•21 years ago
|
||
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...
Reporter | ||
Comment 27•21 years ago
|
||
*** Bug 224745 has been marked as a duplicate of this bug. ***
Comment 28•21 years ago
|
||
*** Bug 224776 has been marked as a duplicate of this bug. ***
Comment 29•21 years ago
|
||
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.
Comment 30•21 years ago
|
||
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.
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•