Closed Bug 165199 Opened 22 years ago Closed 22 years ago

Trunk build does not start (alert window blocks)

Categories

(SeaMonkey :: Installer, defect)

Product:
SeaMonkey
Component:
Installer
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
VERIFIED WORKSFORME

People

(Reporter: 3.14, Assigned: dveditz)

References

(
URL
)

Details

(Keywords: regression)

Attachments

(2 files)

First window which came up
5.68 KB, image/png
Details
The second (the alert) window
791 bytes, image/png
Details 
The newest trunk, i.e.,
File: mozilla-win32-installer-sea.exe  10790 KB  08/28/02  09:29:00
cannot be started.

When I do, a window with title "Alert" comes up. The window is so small that you
cannot see anything. It cannot be resized. My guess is that it asks about change
of system defaults in Windows. So I cannot do anything -> blocker

pi
I gave it one more shot. I not only uninstalled Mozilla, I also deleted manually
the folders in the Mozilla directory (not plugins). A new install did work
again. I leave this bug open now for someone to check. Most people will not be
able to handle this problem.

pi
Confirming on WinXP 2002082804 trunk. The workaround that Boris described does
work, but normal users will never get that far.
I'm currently using 2002082804 trunk under XP to enter this comment.

So, obviously, it WFM.

I experiencd the behaviour described when installing on top of my old build, but
after deleting the Mozilla directory and installing again it worked.

> The workaround that Boris described does work, but normal users
> will never get that far.

This issue has come up before - where you have to uninstall an old version
before a new build will run properly.  But, as far as I know, it's never
necessitated the additional step of manually removing the Mozilla directory.

I'm not sure if this bug is illegitimate (WORKSFORME), or if the workaround
(deleting the directory in addition to the uninstall) is too onerous to be an
acceptable solution.

OS->All anyway.
OS: Windows 98 → All
I also had this problem on another Win98SE (German) machine. This time two
windows came up, see attachments to come.

As a workaround I played around. I had to delete the components folder, only its
Netscape subfolder was not enough. Deleting the chrome folder did not help.

pi
OS: All → Windows 98
I missed to say: Back to Win98, all suggest that it happens outside Windows for
which we don't have evidence yet.

Anyways, here the first of the two windows. This came up with the first start.
On the seconde (and later) starts the second window showed up, which was the
one from my original report.

pi

    
    

    
  
<off topic>

There really should be general OS categories (Win32, MacOS, *NIX) so as to avoid
issues over whether to use All or not.  Obviously, marking it as "Win98" is
wrong, since it also happens under XP - but I suppose "All" may equally wrong if
it's limited to just Win32...

</off topic>

    
    

    
  
Jason, your are looking for bug 12309.

pi

    
    

    
  
I confirm on NT the very same behavior Boris has in the attachments 
to comments 5 & 6.

I tried uninstalling first, didn't help.  I had to fall back to
a saved build ( 8/19 ) and install that.



    
    

    
  
> I tried uninstalling first, didn't help.

Did you also delete what was left of your Mozilla program directory after the
uninstall?  (It seems like it's safe to keep the Plugins directory though.)

    
    

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

    
    

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

    
    

    
  
OS -> All again since now it's been reported under MacOS.  (From bug 165146.)
OS: Windows 98 → All

    
    

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

    
    

    
  
*** Bug 165285 has been marked as a duplicate of this bug. ***
Severity: blocker → major

    
    

    
  
Bug 165306, an obvious dupe of this one, was marked a dupe of bug 162593 (which
is "solved" by manually deleting components/compreg.dat).

Either bug 164306 should be re-duped here - or this bug should be marked as a
dupe of bug 162593 also...

    
    

    
  
A buggram recommended deleting compreg.dat to solve the installation and it did,
but, you still can't start the email client.

harvey r. savage
hsavage@pobox.com

    
    

    
  
Uninstalling and reinstalling does not work for me on Mac OS9 (bug 165146).

    
    

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

    
  
Depends on: compreg.dat

    
    

    
  
Which fix (we know exactly the day) caused this?

pi
Keywords: regression

    
    

    
  
Deleted everything, including the profiles folder, and downloaded and installed
again on OS9 (bug 165146).
Slightly differen behaviour this time, instead of a tiny window in upper left
hand corner, I now have a even tinier window exactly centered on the screen.
This window can't be resized.

    
    

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

    
    

    
  
Vidar: If the 8/29 builds do not allow you to install Mozilla on MacOS (after
completely deleting or renaming your Mozilla program directory) then the
severity here should be raised to Critical.

    
    

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

    
    

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

    
    

    
  
Sgould the fact that Mozilla fails to start unless you delete compreg.dat 
(seperatly from the uninstall process) mean that this is a crash? I'm thinking 
that the severity should be increased one level.

As an aside, how on earth did this pass smoketests?

    
    

    
  
WRT the 2002-08-29 build, YES - deleting the entire "components" directory after
uninstalling does allow me to install the build cleanly.

Curiously, doing so did /not/ require a reboot altho' the failed installation
earlier (Bug#165482) did require a reboot.  That's maybe a clue that the bad
install found a file 'busy' that it tried to install or delete.

This requirement to uninstall (and worse do local file management) is a nuisance
and not at all what Windoz users expect.  Isn't there a bug open to cure this?

    
  
Blocks: 165604

    
    

    
  
> how on earth did this pass smoketests?

I'm guessing because some testers either remove the entire program directory or
compreg.dat (but see comment 17 here) as part of their uninstall routine and/or
are on a platform that, for whatever reason, isn't experiencing this problem.

As to why this does not have the keyword "smoketest", and was reduced from
Blocker to only Major (rather than at least Critical) is beyond me.

Several bugs that have been marked dupes of this have the comment "always remove
old mozilla before installing" - this is misleading since, for instance,
Add/Remove under Win32 is *not* sufficient.  In my mind this is a defect of
Mozilla's uninstall routine (Add/Remove *should* be sufficient) and/or the
install routine.  The fact that it isn't is not the user's fault.



    
  
Depends on: 113593

    
    

    
  
I have it encountered this bug after i installed build 2002082914 over previous
verison on Win98 SE Czech edition.
I have just run regxpcom.exe from folder where Mozilla is installed and that
solved the problem as Mozilla started correctly.

    
    

    
  
Build 2002082908 worksforme, after deleting everything mozillaish and rebooting.

    
    

    
  
Comment 28: Matti said that it is not a blocker, because *developers* can simply
get it to work.

Comment 29: Let me get this straight. You installed a new version and it did not
work. The only thing you did to get it work was running regxpcom?

Comment 30: I don't understand what exactly and when you deleted.

Why should this bug her block bug 165604? That one is a dupe anyways. IIRC to an
invalid bug.

pi

    
  
No longer blocks: 165604

    
    

    
  
> it is not a blocker, because *developers* can simply
> get it to work.

Understood, but why is it not Critical?

> Why should this bug her block bug 165604?

At the time it wasn't marked a dupe - and of an INVALID bug at that.  I've
removed the dependencies.

    
    

    
  
Comment 31: (Comment 30) I simply searched for files named moz* and deleted
everything I found, in addition to program and profile folder.

    
    

    
  
Helo,
I'm using build 2002082914 on windows xp and I got the same tiny alert window
when I launched mozilla but I tried running regxpcom.exe and that fixed it
without even haveing to reboot so if someone would modify the installer to run
regxpcom.exe after installing mozilla that should fix this bug.

Thanks,
John Ilves

    
    

    
  
Helo,
I'm using build 2002082914 on windows xp and I got the same tiny alert window
when I launched mozilla but I tried running regxpcom.exe and that fixed it
without even haveing to reboot so if someone would modify the installer to run
regxpcom.exe after installing mozilla that should fix this bug.

Thanks,
John Ilves

    
    

    
  
With the last several issues, latest is 2002082914, on Win98 SE, I have been
getting a complete install.  No Alert window, just the browser.  

This complete install takes places whether I install on top of, or, uninstall
and delete some of the Mozilla folders.

I've tried running regxpcom.exe to cure the email client startup to no avail, I
didn't need to run it for the browser to start.

harvey r. savage
hsavage@pobox.com

    
    

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

    
    

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

    
    

    
  
Cc'ing some people who may be able to help.

/be

    
    

    
  
To summarize then: sometimes just deleting compreg.dat fixes things; sometimes
running regxpcom.exe fixes things; sometimes deleting the entire Mozilla
directory fixes things; and sometimes there is no fix and recent Mozilla Mozilla
builds (or at least the Mail component) won't start no matter what steps are
taken.  Regardless, the regular methods of removing the previous version of
Mozilla are ineffective.

Is that accurate?

    
    

    
  
Jason asked,

------- Additional Comments From jasonb@dante.com  2002-08-30 15:56 -------
To summarize then: sometimes just deleting compreg.dat fixes things; sometimes
running regxpcom.exe fixes things; sometimes deleting the entire Mozilla
directory fixes things; and sometimes there is no fix and recent Mozilla Mozilla
builds (or at least the Mail component) won't start no matter what steps are
taken.  Regardless, the regular methods of removing the previous version of
Mozilla are ineffective.

Is that accurate?

I answered,

Not quite accurate,

Jason,

I don't know whether to answer you directly or go to additional comments on the
bug page. But, here goes.

I'm using Win98 SE, from about the last 7 or 8 issues I've had no problem
installing Mozilla.  Don't know the issue # that started working again, sorry. 
Installations and browser startup are as smooth as ever now, this is after
deleting nothing, and after deleting most of the Mozilla folders.  Either way
works fine for installing the browser.  Regxpcom.exe never helped me much.

For the mail component go back to bug 164526, that's when the mail client
stopped loading completely.  On a new install mail will load 1 time, usually,
and will not load again completely again until you go back and do another reinstall.

It does load part way, do Ctrl/Alt/Delete and see it in the list of running
programs, but you never see any screen display therefore you can't read, receive
or send email.

Ctrl/Alt/Delete and then close Mozilla is the only way to clear it from memory,
you must do that before the installer allows you to reinstall.

harvey r. savage



    
    

    
  
> For the mail component go back to bug 164526

Okay, I'm going to consider this as a separate bug then - treating the Mail
component issue as not relating to what's going on here.

Taking the above out of consideration, and carefully re-reading all of the
previous comments here, it would now appear that those experiencing this problem
can get Mozilla to start by either removing compreg.dat or running regxpcom.exe.

I don't know this for sure, but I'm assuming that regxpcom.exe simply rebuilds
compreg.dat?  If that's the case, then it's probably safe to say that the
workaround to this bug is to simply remove compreg.dat (which will be rebuilt
automatically the next time Mozilla's run anyway).

So, after all of this, it looks very much like a "dupe" of bug 162593 - at least
in the sense that if that one's fixed, this one will be too.  I'm thinking now
that no more work needs to be done in *this* bug, but in the other.  (Although
this bug should probably remain open, at least as a "place holder" to which
future bugs can be duped - the discussion/summary text here is a lot more
specific to what's been happening recently than is that for the other bug.)

    
    

    
  
Ok.
I used trunk versions up to Mozilla 1.1. Then i installed full Moz1.1 and used
it to this day.

Today i installed trunk version and got this bug. I tried every
trunk/build/relase. Always this bug.

Running regxpcom.exe fixed it.

I think that there are minimum two different bugs with this...

    
    

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

    
    

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

    
    

    
  
clear dupe of bug 162593

*** This bug has been marked as a duplicate of 162593 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE

    
    

    
  
Not a dupe.  Please read through the comments in both bugs.

The solution to bug 162593 is to delete compreg.dat.  However, the solution to
this but is to do either that OR run regxpcom.exe.  (Running regxpcom.exe does
not fix bug 162593.)  Additionally, this bug is open to specifically address
whatever was checked in between 8/27 and 8/28 that caused 8/28 and later builds
not to run.

They are similar, but not identical.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---

    
    

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

    
    

    
  
->installer 
Assignee: asa → dveditz
Status: REOPENED → NEW
Component: Browser-General → Installer
QA Contact: asa → bugzilla

    
    

    
  
Really installer? It happens after the installation when the browser is started
and on later starts.

pi

    
    

    
  
He's right - it's the installer that's causing the problems. Whatever it is that
we need to do to fix this, sometimes delete compreg.dat, sometimes run
regxpcom.exe, the installer should do that automatically for us.

    
    

    
  
On second thought, it would be more beneficial to nail down exactly what caused
the problem.  Modifying the installer can certainly prevent it from happening,
but there could still be "bad code" out there that should really be cleaned up.

Does anybody yet know what 8/28-8/29 check-in caused the issue?

    
    

    
  
As I see it there are two sides to this problem (and I'm not talking about the
two differant manifestations). We need a fix for 1.2 (especially as 1.2a is
coming up very soon), and secondly, we need to fix the root cause of the problem.

So, any change to the installer process should be a temporary change until the
real problem is found...(and yes, I'm assuming it may take a while to find the
real problem).

    
    

    
  
Fair enough.  Then this bug should be about addressing the root cause (long
term), while bug 162593 will (hopefully) fix the short term installer problem.

Therefore, this bug does not belong under the Installer component - since what
we want here is to get to the real cause of the problem, not just apply a quick fix.

-> Browser-General until the actual problem from 8/27-8/28 is identified.
Component: Installer → Browser-General

    
    

    
  
.
Assignee: dveditz → asa
QA Contact: bugzilla → asa

    
    

    
  
How is this not installer. It doesn't make sense to move this from a component
that is the "closest we know right now"  to a component which is "definitely,
absolutely, not the right place". ->Installer. The installer should do what it
takes to work with previous builds. 
Assignee: asa → dveditz
Component: Browser-General → Installer
QA Contact: asa → bugzilla

    
    

    
  
Okay.  I doubt it is an Installer issue but until we determine where it does
belong I suppose it can stay here.

    
    

    
  
It is an installer issue. For some reason installer doesn't manage to do full
autoregistration. Bug 162593 would be an enhancement to handle non-installer
setups better. 

    
    

    
  
> For some reason installer doesn't manage to do full autoregistration.

Yes, but this has been a problem since BEFORE 8/28, and it never resulted in the
symptoms reported in this bug.  This bug only started happening on 8/28 -
Mozilla failing to start and displaying the Alert box instead.

What was it that was checked in on 8/27 that caused this *specific* problem?

    
    

    
  
I think the installer has been broken for a while, but recent major component
changes caused the symptoms. It could have been broken for a longer time (when
was component.reg abandoned, btw?).

    
    

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

    
    

    
  
> recent major component changes caused the symptoms

<sigh> But, again, we don't know which 8/27 component change?  Until we can
pinpoint what it was, debate on whether it's the installer or not is moot - and
we'll never determine what the actual cause is...

I can list the bugs marked FIXED on that date, or look at the actual Bonsai
checkins, but I don't know enough to figure out which one could have been the
culprit.

    
    

    
  
<sigh> We've had problems at least since 20020813 when a uconv change was
checked in. Maybe 20020828 was the first one that didn't start at all, but there
have been multiple problems caused by this for over three weeks now. 

    
    

    
  
Okay, this is simple.  If you're interested in the "installer problems" that
have been around since 8/13 (or whenever) then you shouldn't be following this
bug.  You should be following bug 162593.  This bug is not specifically about
the installer problems.  It is *specifically* about Mozilla throwing up an Alert
box and not starting.  The two are most likely related (in fact, bug 162593 is
marked as blocking this one), but they are not the same.

Saying that the "cause" of this bug is installer problems doesn't address the
actual issue.  Fixing the installer *may* fix this bug, and it *may* fix it
correctly, but until we can identify the piece of code that caused these
*specific* (Alert box, Mozilla not starting) problems, this bug may only be
covered up, and the symptoms masked, rather than dealt with properly.  It's
possible that the code checked in is faulty in some way and cleaning it up will
again let Mozilla run properly without an Alert box *even with* the installer
problems still in existence.

If all I wanted to do was get Mozilla to start properly (and I have) I'd only
have to apply the workarounds here and wash my hands of it all.  Or go back to
the 8/26 build.  The bug being discussed here (Alert, not starting) was NOT
present in the 8/26 build (even if the installer problems were).

At this point, in dealing with *this* bug, we should determine what 8/27 checkin
*specifically* caused the Alert to be thrown and Mozilla not to start.

    
    

    
  
Am using Windows 2000 Professional........
I originally submitted bug report 166464. It seems that it was a dupe of this
one. Reading thru the comments and suggestions I found it interesting that
deleting compreg.dat file would correct this problem. It also was suggested you
do an uninstall first. Since the compreg.dat file is left behind when that is
done deleting all files and folders pertaining Mozilla would be a wise move too.
Doing so would eliminate the dat and any other files that could cause the
problem. Maybe I'm opening a can of worms here but I'd like to add this
information about what I did to correct this problem.
First: I un-installed, using the Mozilla un-install from my programs list(not
the ADD/remove programs on the control panel).
(Boris suggested that anytime you updated an un-install should be done.)
Second: I deleted compreg.dat file from the components folder left behind after
the un-install was done.
(As suggested in this bug report)
Third: I re-installed the last nightly build I downloaded (2002090314). Once the
install was done Mozilla opened correctly this time without the "Alert" window
showing up.
Fourth: I downloaded the lastest nightly build(20002090408). 
Fifth: Without deleting compreg.dat file  or un-installing the previous build, I
 ran the install exe (mozilla-win32-installer-sea.exe). Once the install was
completed Mozilla opened fine.
Sixth: Also checked to see if there was a problem with the e-Mail client. None
was found.
My conclusions:
It would seem that there was a problem with some older versions of the
compreg.dat file or someone messed with it. Once deleted and a new one installed
it cleared up the problem (Alert Window or other opening). It also may be a
problem with the OS (Windows, Mac, etc ) not recognizing a new compreg.dat file.
I have learned that with any program there should be a smooth transition from
the currently installed version to an update or upgrade of any program.
Un-installing any program doesn't really get rid of all files associated with
it. Unless you do a time consuming file by file deletion, even registry editing
too. Finally, if there was a change made in the code that caused this, then why
are you able to do one workaround then not do the workaround and have the
problem disappear either way. Maybe Jason is correct in saying that there is a
root cause to this and everyone is looking in the wrong direction. I also agree
that this should be a "Critical" bug requiring the attention of all those who
are supplying code, changes , etc.

    
    

    
  
Quoting a comment#2 from Bug#164526 :
"Time to time, Mozilla gains a "critical mass" of changes that make it
incompatible with its own internal config files from previous betas. In that
case, the following sequence of actions is recommended:

1) Uninstall Mozilla using its own uninstaller
2) Completely erase the contents of Mozilla directorty (c:\Program
Files\mozilla.org\Mozilla by default); you may leave Plugins directory intact
though.
3) Install new version.

"

IMNSHO, what's missing is basic Configuration Management.  If a file format
changes, particularly in a non-compatable way, then its NAME should change, e.g.
from compreg011.dat to compreg012.dat.  Likewise, good CM would dictate rolling
the minor version number (to 1.2 or whatever).  Of course, the latter has some
"political" or PR ramifications that may overrule "good CM," unhappily that
happens all the time.

    
    

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

    
    

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

    
    

    
  
Bug 162593 has been marked FIXED (and the equivalent of running regxpcom.exe
with each install now occurs).  It will be interested to see if the Alert
behaviour continues with the 9/5+ builds.  (Hopefully not.)

    
    

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

    
    

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

    
    

    
  
Has this problem been observed to be fixed in today's builds?

    
    

    
  
I uninstalled and reinstalled 2002090504, as is usual in my case (Win98), the
installation went great and the browser had no apparent problems that weren't
there before this last couple of weeks. 

The email client however didn't fare as well, it started, as usual (it won't
start a second time with another install), the first message I viewed took
control of the view window (pane), and I could do nothing to view another message.

harvey r. savage
hsavage@pobox.com

    
    

    
  
After two weeks, my Mozilla 1.1 install on a Windows XP machine, displayed the
same problem. I tried all the various solutions offered: deleting compreg.dat,
running regxpcomp.exe, uninstalling then deleting compreg.dat and nothing worked
until I uninstalled then re-installed in a brand new directory. 

    
    

    
  
FYI: I am using build 20020826

    
    

    
  
I just installed the 9/5 build (20020905) and it installed with no problems, the
first build since 8/26 to do so on my Win98SE PC. So maybe fixed?

    
    

    
  
Closing bug as WFM.

To test, I installed 1.1 release. The error originally showed up after replacing
that version with a trunk build. Then I installed (after simple uninstall, no
manual deletion) Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.1b)
Gecko/2002090504. No problem.

pi
Status: NEW → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → WORKSFORME

    
    

    
  
Someone please tell me, are we following a very narrow focus and referring only
to the Alert window when installing one of these current builds. 

I hope thats the case because I haven't had an install, up to and including
build 2002090511 where I can use both the browser and email.

I know this started with the Alert window but, in my case, that only lasted thru
about a half dozen builds.

If I want to have email I always have to reinstall an old build, 2002081308,
before I have full functionality.

harvey r. savage
hsavage@pobox.com

    
    

    
  
Harvey, that would be another bug, which was duped onto bug 162593 IIRC.

pi

    
    

    
  
Harvey: Take a look at bug 162891 for Mail/News not starting specifically.  In
particular, see bug 162891 for a workaround, use one of the built-in themes, or
update any 3rd party theme to the most recent.

    
    

    
  
Thanks for suggestion to change to one of the original themes  

I upgraded my preferred theme, Pinball, to version 1.0.4, and on the latest
beta, 2002090604, I got a complete install and as a bonus my email now works.

Keeping themes upgraded seems to be critical.


harvey r. savage
hsavage@pobox.com

    
    

    
  
Verified WFM
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: