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: