User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322) Build Identifier: seamonkey/nightly/2005-07-16-07-trunk/ Seamonkey cannot be started at all, it immediately exits, most of the time without any visible indication of it running. Mozilla 1.7.2 ran fine on this machine, so I tried to upgrade, after which I could not start up seamonkey, so I uninstalled seamonkey, mozilla, and deleted the profile and registry entries, but the same failure to start up still occurs. Reproducible: Always Steps to Reproduce: 1.Install Seamonkey 2.Start up seamonkey Actual Results: Seamonkey immediately quits, sometimes I am able to see the splash screen for a split second. Expected Results: Started up Operating System: Windows XP Professional Service Pack 2 Processor: Pentium M 2GHz RAM: 2GB Antivirus: etrust Antivirus 7.0.139

Confirming; using the stub installer, I see the same behavior.

But .zip builds such as seamonkey-1.0a.en-US.win32.zip 16-Jul-2005 10:27 11M are fine.

apparent bustage from bug 298044

Same occurs with 7/17/2005 build. Build identifier: /seamonkey/nightly/2005-07-17-06-trunk/

Same here, WinXP Pro SP2 using seamonkey/nightly/2005-07-16-07-trunk/

I think we can safely say that this problem is confirmed. No reason to keep saying that you see it. <grin> I do question, however, the fact that this hasn't yet been set as a blocker bug. Since we're talking about SeaMonkey now, and not Mozilla, I don't know if the same criteria apply? Robert?

(In reply to comment #7) > I do question, however, the fact that this hasn't yet been set as a blocker bug. cbiesinger@gmx.at 2005-07-16 13:30 PDT Flag blocking-seamonkey1.0a? blocking-seamonkey1.0a+ i.e. blocking status was set 2 days ago.

That's what I get for being too vague. <grin> I'd meant raising the severity to "blocker". Isn't this preventing smoketests from running on the installer version of SeaMonkey?

This was caused by a change in design of the XPCOM glue: The standalone XPCOM glue is now loading the dependent libraries that XPCOM needs (xpcom_core.dll) but is not loading the dependent libraries that are needed by the application (gfx, js, probably some mailnews stuff). There are two solutions: an expedient solution that wallpapers over the problem and a good solution that will require some work from seamonkey. 1) EXPEDIENT: add the GRE path to the PATH envvar in the windows version of XPCOMGlueStartup. This is a hack because it only works on windows, and it isn't really "correct", see #2. 2) CORRECT: In between calling XPCOMGlueStartup and NS_InitXPCOM2, the apprunner should manually load whatever dependent libraries are required by that application. The reason this is not easy is that seamonkey currently uses the (rather broken) GREStartup() function instead of separate XPCOMGlueStartup and a custom directory provider passed to NS_InitXPCOM2. I can provide a patch for solution #1, but I encourage the seamonkey coders to get their act together, implement a real dirserviceprovider for seamonkey, and load the proper dependent libs in the apprunner.

So is the -greLocal installer option a workaround?

It should be, yes.

My findings are indeed that running C:\Documents and Settings\Owner\Desktop>seamonkey-1.0a.en-US.win32.stub-installer.exe -greLocal from the command line results in a successful installation. ;-)

Confirming the success of Stephen's workaround on Windows XP Home - Service Pack 2. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050719 SeaMonkey/1.0a

*** Bug 301235 has been marked as a duplicate of this bug. ***

(In reply to comment #10) >The standalone XPCOM glue is now loading the dependent libraries that XPCOM >needs (xpcom_core.dll) but is not loading the dependent libraries that are >needed by the application (gfx, js, probably some mailnews stuff). OK, so where was the code that used to load js etc? Also, is there any reason not to hack GRE_Startup, surely anyone who used it would be affected?

This is the patch to hack GRE_Startup... it builds (I added the printf for debugging, it should be removed before final checkin). I need somebody to build windows seamonkey+installer to test it before I request review. I would actually prefer that seamonkey stopped using the GRE and went back to -grelocal by default.

Comment on attachment 190021 [details] [diff] [review] Hack GRE_Startup() this patch does make seamonkey start up correctly. + printf("newpath = %s\n", newPath); that should probably be removed

Comment on attachment 190021 [details] [diff] [review] Hack GRE_Startup() deferring to bsmedberg since he's the one who's been hacking GRE code lately.

darin: it's his patch...

Comment on attachment 190021 [details] [diff] [review] Hack GRE_Startup() Yeah, it's my patch ;-)

*** Bug 301843 has been marked as a duplicate of this bug. ***

*** Bug 300878 has been marked as a duplicate of this bug. ***

Comment on attachment 190021 [details] [diff] [review] Hack GRE_Startup() Sorry, I only looked at who assigned r= to me :-P >Index: xpcom/glue/standalone/nsXPCOMGlue.cpp >+ printf("newpath = %s\n", newPath); please kill this printf before checking in. r=darin

Today's "nightly" build still has this problem. So, wouldn't it help to set this to be a priority 1 and the target milestone to be SeaMonkey1.0alpha, also?

(In reply to comment #25) > Today's "nightly" build still has this problem. So, wouldn't it help to set > this to be a priority 1 and the target milestone to be SeaMonkey1.0alpha, also? No, it wouldn't help, as reviews won't happen faster just because those are set, and additionally, those are for the assignee to set for his own planning. The blocking-seamonkey1.0a is enough to see that we won't ship that release without that fix, and severity set to blocker is enough to show it's a bad bug. (Additionally, there's even a known workaround available.) BTW, Benjamin, shouldn't we seek the rest of needed reviews/approvals and drive it in?

Comment on attachment 190021 [details] [diff] [review] Hack GRE_Startup() fwiw, a=me though nobody asked for it

Fixed on trunk for 1.8b4

Just downloaded latest version this morning... Does not work!

Same for me with build 2005072605, same behaviour as with any installer build of the last days.

Please, people. The fix was landed at 2005-07-26 07:12 PDT, which means it was around 2 hours after the build was created. It'll be available in tomorrow's build.

Verified fixed in today's (27 June) trunk build.

*** Bug 302323 has been marked as a duplicate of this bug. ***

This bug has occurred again in SeaMonkey XP 2005-09-17.

(In reply to comment #34) > This bug has occurred again in SeaMonkey XP 2005-09-17. Yes, but it's filed as bug 308838.