Closed Bug 297725 Opened 19 years ago Closed 19 years ago

[MAS, v1.8b2-0614+] Install Seems to Complete - Mozilla Does Not Load

Categories

(SeaMonkey :: Installer, defect)

Product:
SeaMonkey
Component:
Installer
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
seamonkey1.0alpha

People

(Reporter: therubex, Unassigned)

References

Details

(Keywords: qawanted, regression, Whiteboard: [Workarounds: see comment 13 template .reg file, or "-greLocal" install commandline])

Attachments

(3 files)

RegMon Log: (Win98SE) start failure
17.39 KB, text/plain
Details
Proposed patch
1.32 KB, patch
Details | Diff | Splinter Review
Use $GreUniqueId$
700 bytes, patch
benjamin
: review+
benjamin
: approval1.8b3+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050613
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050614


Download Installer.  Everything proceeds normally, till the time when either
Mozilla should start, or the Profile Manager should load.  Neither happens.
Mozilla will not run.


Reproducible: Always

Steps to Reproduce:

Uninstall Existing.
Delete GRE.
Delete Profiles.
Delete registry.dat ...

Download either stub-installer or complete install (win32).
Run install.
Select Custom.
User defined install location.
Browser, DOM Inspector, & Talkback only.

Actual Results:  

Install proceeds - GRE, Mozilla itself, uninstall ...
After you see uninstall installing, a short time later thats it. Nothing.

Mozilla does not open, Profile Manager will not load.

If I recall correctly, /Application Data/Mozilla/ never gets created, nor does
/Local Settings/Application Data/Mozilla/


Expected Results:  

Mozilla should have installed correctly & run.


20050613 does install correctly.
Confirming this  is happening with the Mozilla Trunk Nightly 20050614 on both 
Windows XP and Windows 2000
Another confirmation here:

Mozilla Trunk Nightly 20050614 Windows XP.
Status: UNCONFIRMED → NEW
Ever confirmed: true
This is caused by the changes to the GRE glue code in bug 224305. The seamonkey
GRE registration will need to set a Version= key to be compatible with the new
registration system.
Component: General → Installer
*** Bug 297812 has been marked as a duplicate of this bug. ***
Severity: major → blocker
Version: unspecified → Trunk
Flags: blocking-seamonkey1.0a+
Confirming also, this time with a 16 June nightly build.
Confirming in June 16 build
Please don't add further confiramtions here. We already know it's happening and
comment #3 tells the cause, we just need someone to fix that issue.
You might see we (the SeaMonkey Council) even agreed that this is blocking the
upcoming developer release of the suite, so please don't add further comments
unless you can help in fixing this bug.
*** Bug 298018 has been marked as a duplicate of this bug. ***
Depends on: 224305
Keywords: regression
Summary: Install Seems to Complete - Mozilla Does Not Load → [MAS, v1.8b2-0614+] Install Seems to Complete - Mozilla Does Not Load
Target Milestone: --- → Seamonkey1.0alpha
From https://bugzilla.mozilla.org/attachment.cgi?id=185790

+  // Formerly, GREs were registered at the key
HKLM/Software/Mozilla/GRE/<version>
+  // valuepair GreHome=Path. Nowadays, they are registered in any subkey of
+  // Software/Mozilla/GRE, with the following valuepairs:
+  //   Version=<version> (REG_SZ)
+  //   GreHome=<path>    (REG_SZ or REG_EXPAND_SZ)

As bsmedberg said in comment #3, it looks like we only need to fix our installer
to also set the "Version" registry key along with the "GreHome" key it already
sets. Note that "any subkey" means for us that we should continue using
<version> from how I understand bug 224305 comment #7 so it should really be as
easy as adding the one value pair and be done for now.
From IRC:

<Unghost> I've exported this part to file:
<Unghost> [HKEY_LOCAL_MACHINE\SOFTWARE\mozilla.org\GRE\1.8b2_2005061705]
<Unghost> "Version"="1.8b2"
<Unghost> "BuildID"="2005061705"
<Unghost> "GreHome"="C:\\Program Files\\Common
Files\\mozilla.org\\GRE\\1.8b2_2005061705"
<Unghost> "GreComponentsDir"="C:\\Program Files\\Common
Files\\mozilla.org\\GRE\\1.8b2_2005061705\\Components"
<KaiRo> there's already a "Version" key?
<Unghost> yeap
<KaiRo> interesting...
<Unghost> I've changed 1.8b2 to 1.8b2_2005061705 and Mozilla started up!!!
<KaiRo> now that's interesting

Note that the comment quoted above is wrong in that it's "mozilla.org" and not
"Mozilla", maybe we should patch that as well...

For the fix itself, it should probably be happening at
http://lxr.mozilla.org/mozilla/source/xpinstall/packager/win_gre/gre.jst#39
and/or
http://lxr.mozilla.org/mozilla/source/xpinstall/packager/build/win/gre/XPI_JSTs/gre.jst#39
*** Bug 298141 has been marked as a duplicate of this bug. ***
*** Bug 298152 has been marked as a duplicate of this bug. ***
[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050619] (nightly)
(W98SE)

Confirming what key(s) MAS startup code is looking for.

(In reply to comment #10)
> <Unghost> I've changed 1.8b2 to 1.8b2_2005061705 and Mozilla started up!!!

Confirming workaround/fix:
I "renamed/created" the key+value pair, then -0619 started/works as expected
{{
REGEDIT4

[HKEY_LOCAL_MACHINE\Software\mozilla.org\GRE\1.8b2_2005061905]
"Version__ORIG"="1.8b2"
"Version"="1.8b2_2005061905"
}}
*** Bug 298157 has been marked as a duplicate of this bug. ***
*** Bug 298154 has been marked as a duplicate of this bug. ***
*** Bug 298235 has been marked as a duplicate of this bug. ***
Instalation appears normal until the point at which the splash screen should
pop-up, installation is halted, doesn't appear in Windows installed software
list and cannot be started from the Desktop icon.
Whiteboard: [Workaround: see comment 13 template .reg file]
(In reply to comment #13)

> [HKEY_LOCAL_MACHINE\Software\mozilla.org\GRE\1.8b2_2005061905]
> "Version__ORIG"="1.8b2"
> "Version"="1.8b2_2005061905"

So we're looking at [HKEY_LOCAL_MACHINE\Software\mozilla.org\GRE\<VERSION>] to
ascertain what the <VERSION> is?

This strikes me as being completely pointless and a bit dumb!
(In reply to comment #18)
> So we're looking at [HKEY_LOCAL_MACHINE\Software\mozilla.org\GRE\<VERSION>] to
> ascertain what the <VERSION> is?
> 
> This strikes me as being completely pointless and a bit dumb!

This has it's reason (the part after "GRE" in the path can actually be anything
in the future, it doesn't have to be the version number any more, but it's kept
for for for compat reasons).
Anyways, this bug report is not here to argue about what's reasonable for core
stuff like GRE to do, just to make SeaMonkey compatible with the recent changes
that happened there.
Part of the reason for the change was so that you could have multiple GREs of
the same version installed at the same time (think xulrunner and MAS,
perhaps!?). For this to work effectively, both xulrunner and MAS must not
overwrite the other's registry keys, so I suggest that MAS use the following
convention:

HKEY_LOCAL_MACHINE\Software\mozilla.org\GRE\Sea_<VERSION>

(or whatever makes sense to you)

xulrunner uses the following convention:

HKEY_LOCAL_MACHINE\Software\mozilla.org\GRE\<VERSION> is tried first, and if it
already exists, xulrunner starts looking through
HKEY_LOCAL_MACHINE\Software\mozilla.org\GRE\<VERSION>_0 (1, 2, 3...) until it
finds an unused key, and registers there. It saves which key it registered in
for later correct uninstallation.
(In reply to comment #20)
> HKEY_LOCAL_MACHINE\Software\mozilla.org\GRE\Sea_<VERSION>
> HKEY_LOCAL_MACHINE\Software\mozilla.org\GRE\<VERSION> is tried first, and if it
> HKEY_LOCAL_MACHINE\Software\mozilla.org\GRE\<VERSION>_0 (1, 2, 3...) until it

Then HKEY_LOCAL_MACHINE\Software\mozilla.org\GRE\<VERSION>_Sea and <VERSION>_?_Sea
Or HKEY_LOCAL_MACHINE\Software\mozilla.org\GRE\<VERSION>_Sea and <VERSION>_Sea_?
depending on which sort order makes more sense. (the later !?)

(my 2 cents worth)
*** Bug 298394 has been marked as a duplicate of this bug. ***
Another workaround: Launch the installer with the "-greLocal" command line. If
the GRE files are found in the install directory (as they are with the working
.zip builds) then Mozilla never looks at the registry.
Whiteboard: [Workaround: see comment 13 template .reg file] → [Workarounds: see comment 13 template .reg file, or "-greLocal" install commandline]
*** Bug 298465 has been marked as a duplicate of this bug. ***
I just did some research again, but my problem is that I'm neither on windows
nor do I know the win installer code.

It looks to me as if we should change
http://lxr.mozilla.org/seamonkey/source/xpinstall/packager/windows/config.it#599
to
SupersedeVersion0=Sea_$GreFileVersion$

and
http://lxr.mozilla.org/mozilla/source/xpinstall/packager/win_gre/gre.jst#39
to
err    = winreg.setValueString(subkey, "Version", "$GreFileVersion$");

(that is, if $GreFileVersion$ works in gre.jst - if not, we might try
"$UserAgent$_$GreBuildID$")

It would be good if someone could try those changes on a windows machine, and
someone who knows something about the code could tell if it's the right way or
not. I'm basically only guessing, I have no real clue about installer code.
Attached patch Proposed patch — — Splinter Review 
Robert,

Close but no cigar.
Just compiled and installed with the patch attached.

Can someone else test this patch, and work out how to get it checked into
MAS/Seamonkey without breaking anything else?
Attachment #187144 - Flags: approval1.8b3?
Please note that the GRE version key depends on whether MOZ_MILESTONE_RELEASE is
set (which it unfortunately has not been for many of our 1.7.x releases):

MOZ_MILESTONE_RELEASE set: "1.8b2"
MOZ_MILESTONE_RELEASE not set: "1.8b2_12345567890"
Attachment #187144 - Flags: approval1.8b3?
(In reply to comment #26)
> Created an attachment (id=187144) [edit]
> Proposed patch
> 
> Can someone else test this patch, and work out how to get it checked into
> MAS/Seamonkey without breaking anything else?

For one thing, please only request approval once the patch is tested and the
needed reviews are done. No need to bother drivers before that stage.

For the other, why do you concat a string with "+" when
"$UserAgent$_$GreBuildID$" (as I proposed) should do the same thing (The $...$
string should get replaced by the real strings by preprocessing)? Have you
tested and failed with that one?

Additionally, the question is how we can address the other issue bsmedberg has
brught up now... probably we should really get $GreFileVersion$ in there and set
that to the correct value while preprocessing the .jst file.
(In reply to comment #28)

> For one thing, please only request approval once the patch is tested and the
> needed reviews are done. No need to bother drivers before that stage.

A million apologies - I'm not very familiar with Bugzilla.

> For the other, why do you concat a string with "+" when
> "$UserAgent$_$GreBuildID$" (as I proposed) should do the same thing (The $...$
> string should get replaced by the real strings by preprocessing)? Have you
> tested and failed with that one?

Yes it DOES do the same thing - I just tested it. I somehow managed to miss your
second proposal and just did a concat out of habit when the first proposal
didn't work.

> Additionally, the question is how we can address the other issue bsmedberg has
> brught up now... probably we should really get $GreFileVersion$ in there and set
> that to the correct value while preprocessing the .jst file.

My feelings are that we should get a patch checked in ASAP to fix the nightlies
and get this off blocker/regression status.
If I understand correctly, the next suite milestone release will be the
Seamonkey 1.0alpha and that will give us some breathing space to implement a
better fix.
This one appears to have the right 1.8b2_ prefix.
Comment on attachment 187159 [details] [diff] [review]
Use $GreUniqueId$

This looks good to me, assuming it works.
Attachment #187159 - Flags: review+
Attachment #187159 - Flags: approval1.8b3+
*** Bug 298621 has been marked as a duplicate of this bug. ***
Fix checked in. Hopefully nightlies will start working now...
Status: NEW → RESOLVED
Closed: 19 years ago
Keywords: qawanted
Resolution: --- → FIXED
(In reply to comment #33)
> Fix checked in. Hopefully nightlies will start working now...

Neil, should we file a followup to address the other things like the
"Sea_<version>" path (comment #20) or the MOZ_MILESTONE_RELEASE issue (comment #27)?
(In reply to comment #33)
> Fix checked in. Hopefully nightlies will start working now...

Confirmed. I`m using Build 2005062403 and the Installer is working fine and the
installer-builds are starting.
v
Status: RESOLVED → VERIFIED
*** Bug 298838 has been marked as a duplicate of this bug. ***
*** Bug 298838 has been marked as a duplicate of this bug. ***
I downloaded the setup 27 June 2005 and this problem still exists.
There is a new problem. 

Mozilla crashs after the Installation and before the Start when you install the
Trunk 2005062605 over an existent Version of Mozilla (like in Programm
Files\mozilla.org\mozilla.

2005062701 don`t start also, but with no crash.

If you delete this folder (rogramm Files\mozilla.org\mozilla), the installation
is running normal (without crash)

I don`t know if this is realted to this Bug, and if not i will file a new one :-)

Talkback Stack:TB7013467G

Stack Signature	 UTF8InputStream::ReadSegments 7a693f77
Product ID	MozillaTrunk
Build ID	2005062605
Trigger Time	2005-06-27 03:05:51.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	xpcom_core.dll + (0001fc45)
URL visited	Crash after install
User Comments	Crash after install
Since Last Crash	2 sec
Total Uptime	2 sec
Trigger Reason	Stack overflow
Source File, Line No.
c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpcom/io/nsUnicharInputStream.cpp,
line 326
Stack Trace 	
UTF8InputStream::ReadSegments 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpcom/io/nsUnicharInputStream.cpp,
line 326]
Driver_HandleExternalEntityRef 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/parser/htmlparser/src/nsExpatDriver.cpp,
line 203]
doProlog 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/parser/expat/lib/xmlparse.c,
line 4374]
prologProcessor 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/parser/expat/lib/xmlparse.c,
line 3615]
MOZ_XML_Parse 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/parser/expat/lib/xmlparse.c,
line 1497]
nsExpatDriver::ParseBuffer 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/parser/htmlparser/src/nsExpatDriver.cpp,
line 836]
nsExpatDriver::ConsumeToken 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/parser/htmlparser/src/nsExpatDriver.cpp,
line 959]
nsParser::Tokenize 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/parser/htmlparser/src/nsParser.cpp,
line 2808]
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Okay, filed a new Bug 298887 about this crash.
Status: REOPENED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → FIXED
back to verified fixed.
Status: RESOLVED → VERIFIED
*** Bug 298963 has been marked as a duplicate of this bug. ***
SeaMonkey/2005072010-trunk/WinXP have this problem.
Reopen?

that's bug 301043
(In reply to comment #45)
> that's bug 301043
Thanks.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: