31020 - Windows build won't start; splashscreen only

Status: VERIFIED FIXED

(SeaMonkey :: Installer, defect, P3)

Description

[sairuh (rarely reading bugmail)]

summary says it all. using opt comm bits 2000.03.08.09 on winNT. start 
mozilla.exe up and all that appears is the splashscreen, which just stays 
there. don't even get the Profile Manager. here's console output:

Profile Manager : Profile Wizard and Manager activites : Begin
Profile Manager : Command Line Options : Begin
Entered MigrateProfileInfo.
Profile Manager : Command Line Options : End
WEBSHELL+ = 1
Java HotSpot(TM) Client VM warning: Setting of property "java.compiler" is 
ignored
Proxy Configuration: Browser Proxy Configuration

JavaScript Error: ReferenceError: srGetStrBundle is not defined
URL: 
chrome://profile/content/profileManager.js
Line number: 23

*** Failed to load 
overlay chrome://global/content/dialogOverlay.xul

apologies if this is a dup/known issue...

Comment 1

[shrirang khanzode]

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

Comment 2

[sairuh (rarely reading bugmail)]

i installed using the installer, btw...

Comment 3

[shrirang khanzode]

Mozilla bits also show the same problem, changing summary...

Comment 4

[sairuh (rarely reading bugmail)]

added appropriate keywords.

Comment 5

[Daniel (Leaf) Nunes]

When i run the build, after the initial install, i get a screwed up (all black,
minus some graphic ghost in the upper left hand corner) `Create New Profile'
window. Is it possible some xul is not getting packaged? I'll look at
yesterday's checkins.

Comment 6

[Daniel (Leaf) Nunes]

looks like packaging is screwed up again:
*** Failed to load overlay chrome://global/content/dialogOverlay.xul

in the console where i hang ("mozilla -console" gives you this output), i'll
find out why this xul file isn't in packaging.

Comment 7

[Daniel (Leaf) Nunes]

packager might have missed some xul files.

Comment 8

[Charles Wang]

I use window 98. I didn't have any problem to lauch today's build. What I did is 
just clicked the win commercial build link on today's build notice. Everything 
is working fine and I completed the smoke test.

Comment 9

[prass]

Adding prass and scalkins to cc list

Comment 10

[Daniel (Leaf) Nunes]

Ok, checked the staging areas, all the correct files are there... checking the
xpi's on the server for corruption (but the .xul files that are missing are
certainly not installed in my local tree)

Comment 11

[Sean Su]

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

Comment 12

[sairuh (rarely reading bugmail)]

i was able to reproduce this on win95.

Comment 13

[Daniel (Leaf) Nunes]

This bug is fixed.

Comment 14

[Grace Bush]

Installing is successful on Win95, NT 

Comment 15

[shrirang khanzode]

I see this problem again on today's windows commercial build(03/09). REOPENING.

Comment 16

[Jon Granrose]

this is the same thing that happened yesterday.  I'm repackaging windows, and it 
should be done shortly.  I'll reannounce when ready.  I'll ask leaf to take 
another look at the win32 automation when he gets in today.

Comment 17

[Jon Granrose]

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

Comment 18

[Jon Granrose]

leaf thinks he knows what's wrong with the automation, so we should be able to 
avoid this problem moving forward.  basically, the perl open() call is timing 
out before pkgcp.pl completes, so he's going to change it to a system() call.

Comment 19

[Daniel (Leaf) Nunes]

Fixed in the automation, verify on the next build (probably tomorrow morning)

Comment 20

[sairuh (rarely reading bugmail)]

weird that i cannot repro this with this morning's bits [2000.03.09.09, opt comm
on winNT]... mozregistry.day was changed upon installation, going by the file
mod date stamp (though i didn't trash it before installation); profiles weren't
changed, though...

Comment 21

[Jon Granrose]

we repackaged the bits.  when we repackage with the new automation, it replaces 
the existing bad bits rather than creating a new directory.  You'll notice the 
timestamp for the directory is 9am, but the files inside it are timestamped in 
the 10 o'clock hour.

Comment 22

[Grace Bush]

verified on build 2000031009