After updating from daily build 4/2/2002 to daily build 4/3/2002, the browser window is just a blank background-colored page - no buttons, no URL bar, no status bar - nothing. The default page seems to get loaded because the title of the page is in the windows title bar. Re-installing build 2002040203 seems to work okay, but clicking on the tray buttons doesn't work now.

I saw this after Blake UI fix and a depend build. But i have no problems with my clobbered build !

Installed without deleting previous build? Wfm on same OS and build 2002040303.

Yes, I installed it without deleting the previous build. I am not sure exactly which build it was from yesterday. I didn't think to check because I am used to Mozilla updating just fine. 8') I have since uninstalled mozilla, rebooted, and reinstalled 2002040303 without installing an old build first, and it works great now.

thanks for your answer -> workfsorme

vrfy.

The same thing happened to me, but it works now after I followed the advice here to uninstall the old version before installing the new one.

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

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

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

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

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

If other people besides me have been able to verify / reproduce this bug, then it is a real bug, and needs to be reopened. In bug 108515, Curt Patrick of netscape stated that it is valid user behavior to install an updated mozilla over an existing mozilla, and therefore a bug if it doesn't work. From Curt Patrick (curt@netscape.com): "But there will always be customers who do install over their old builds, so this is a real bug. We will address it." The component should be changed to installer, however. Some official person please correct me if I'm wrong. 8')

I'd like to note that this same issue happened to me on WinXP with 2002040303. I rebooted and then it worked okay. Not that that is a solution, of course.

Yes, this is a diff from a Linux ls - but this is on a real Windows 2000 install! I just used Linux's ls, diff because I don't have a Windows 2000 diff. 8') mozilla.old is the broken upgrade attempt from a 20020402 build to 2002040303 build. Mozilla is the clean install of 20020403 I noticed the universalchardet.dll file is in the clean install, but not the broken upgrade install. So, I tried copying it in. Still didn't work. The rest of the files look like files created by mozilla as I installed it (4/4). So I think it doesn't have to do with the files, probably something else is going on.

ok, sending this to installer. it's a problem in which either installer doesn't know, or just plain doesn't do a clean uninstall - and - install procedure, so anytime someone checks something in that requires a full uninstall cycle, we're going to get these bugs again. I think it's safe to assume that users will generally not uninstall before hand, just update. I would probably grab zips if this was the case -- extracting a zip is much easier and faster. installer people: can you make it so that it's possible to trigger a full uninstall-before-install cycle? [if that's not too inappropriate?]

We've got to fix this one. THe problem is that an overlay file has been removed from the chrome, but the reference to it persists in bin/chrome/overlayinfo/communicator/overlayinfo.rdf possible fixes (in order of my preference): 1. make the chrome system tolerate missing overlays 2. check in a blank stub in place of the file removed 3. invent a way to uninstall an overlay reference 4. delete the overlayinfo files upon upgrade 2 and 4 are probably the easiest, and are the least desirable. A stub file is just icky (won't be helping performance any). Deleting the overlayinfo on upgrade may leave 3rd-party chrome unregistered afterwards. Any that used the DELAYED_CHROME style are written into installed-chrome.txt and will get re-registered, but packages that don't (AND which overlayed communicator) will need to get re-installed. Better than the browser not starting at all!

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

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

Observed on *2002-04-05* (from Latest), *2002-04-04-08-Win-Gmake* Seamonkey Installs. Same situation: installing over existing install. NOTE also: after going BACK to 2002-04-01, the previously-good installation is broken. The menu bar appears as [*no File*] [*no Edit*] View Search Bookmarks [*no Task*] [*No Help*] Debug QA.

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

The installation appears to also damage the appearance of the MailNews 3-pane view. After un-installing AND re-installing, using Theme "Grey Modern", the MailNews Folder Pane has lost (a) Highlighting of ColumnHeader, (b) Folder Icon (Tree is just lines), (c) *bold* for un-read messages. In general it looks awful. ALSO: The MenuBar has lost the highlighting on mouseover, making it very hard to use. TO RECOVER from this, I deleted all the content of the <userdir>/chrome. Installing again and using Classic I'm OK for now.

We need to do something for RC1.

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

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

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

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

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

I had exactly the same problem (see bug #136029) and for me, the solution was, just to completly remove all files in [PROGRAM-FOLDER]\Mozilla and start installation again. After that, all was working again. No real "uninstall" was necessary. Maybe installer-routines could perform a "delete [PROGRAM-FOLDER]\Mozilla\*.*" before installing the new build.

...and delete profile data possibly stored there ? Bad idea.

Pardon??? Using Windows, profile-data NEVER has to be stored in the programs-binaries-directory!!! It has to be stored somewher under %USERPROFILE%. On Win2k (German), this is by Mozilla-default "C:\Dokumente und Einstellungen\[USERNAME]\Anwendungsdaten\Mozilla\..." So there should never be a problem. So no bad idea. ;-)

I am not sure, where the profile is stored under Win9x/Me, but if it is like the old NS4 does, it is somewhere under [PROGRAM-FOLDER]\Mozilla\user and the binaries are in [PROGRAM-FOLDER]\Mozilla\program. So the only thing, you have to make sure, is that you keep the installed plugins (on all Win*-Systems).

check http://gemal.dk/mozilla/profile.html for where the profile is. To avoid this bug just deleting the mozilla directory before installing a new build or install the new build into a new directory.

Generally a 'rm * -rf' is a very bad idea. Even if there is no profiledata in there. Imagine only one person installing a nightly build - he enters the wrong path, 'C:\Programs' instead of 'C:\Programs\Mozilla'. Checkmate.

ok. I'm pretty sure that you can just rename or delete the file: bin/chrome/overlayinfo/communicator/overlayinfo.rdf and then install on top of the build and it should work.

How about a little note before the install, recommending that the would-be tester delete his moz program folder for better results, and otherwise, for him/her to be prepared for dire consequences...

let's stop the discussion. I'm pretty sure the mozilla/netscape developers already has a way out of this. Dan has already stated how this bug should be fixed. See comment 16: --- possible fixes (in order of my preference): 1. make the chrome system tolerate missing overlays 2. check in a blank stub in place of the file removed 3. invent a way to uninstall an overlay reference 4. delete the overlayinfo files upon upgrade ---

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

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

clarifying summary

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

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

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

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

the bug still exists in 2002040803 os is winxp downgrading as in Additional Comment #19

guys, the issue here is that the installer is not functioning properly. we already have a bunch of possible fixes, which need to be discussed and then fixed. Please stop with the "me too" comments.

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

I take issue with "the installer is not functioning properly". The installer may be asked to resort to drastic measures to fix this (blow away 3rd-party chrome) but it is not the installer that caused the problem.

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

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

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

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

dveditz: should the installer blow away chrome/ and component/ directories at uninstall? if so, then the installer is broken (since last time i did it, it didn't blow away the directories, therefore giving me this problem.) if not, then i take it back. :) could you also clarify what is 3rd party? I would have thought default chrome was ... well default.

these files are not removed during the uninstall phase.

None of those files are installed, therefore they are not uninstalled. You must be using the patch maker tool or something which is expanding your chrome. If you do some developer-like thing like that you're on your own. By "3rd party" I mean things that don't come with Mozilla. If we completely zap chrome and then re-install the browser, mail, inspector, etc. then of course you will get all those back. But if you've installed chrome packages from someplace like MozDev.org or xulplanet, or are developing your own, the Mozilla installer doesn't know that and would erase them in this scenario.

ok, so dveditz and I have established that the files listed there were probably due to a bad build. However, I haven't been able to run an uninstall and have all the files removed; however that's probably due to my machine being possessed *cough* by bill gates's software *cough*.

Decided the stub overlay was the best way to go for now. It's safe and simple, as compared to inventing a way to unregister chrome overlays from the install or brutally zapping parts of the chrome regsitry and forcing people to re-install 3rd party chrome apps. People who install fresh will pay only a small cost in diskspace, the new stub will never be referenced. People who upgrade from a build before 4/2 will be happy to have a usable browser.

Seems like a very short sighted solution. But it will work for now. is there a bug about "1. make the chrome system tolerate missing overlays" ?

Comment on attachment 78318 [details] [diff] [review] re-add a stub overlay to get things going again r=syd

Comment on attachment 78318 [details] [diff] [review] re-add a stub overlay to get things going again r=imajes (fwiw). This should be treated as no more than a hack; we really need a better way of fixing stuff like this than stub files, however the need is greater; we need to prevent the browser stopping working after an upgrade.

Opened bug 136346 on the underlying problem with missing overlays. This will surely come up again and we can't just keep on leaving stubs everywhere.

Comment on attachment 78318 [details] [diff] [review] re-add a stub overlay to get things going again sr=sfraser

Comment on attachment 78318 [details] [diff] [review] re-add a stub overlay to get things going again a=rjesup@wgate.com. If this doesn't make the branch, please ask for permission to check into the branch after applying to trunk.

Just wanted to mention that a few people believe this problem has been leading to a few topcrashers...please see bug 120639 for more. Thought that might help in deciding whether this gets onto the branch or not (I think it would be a good idea).

This has already been approved for the branch, just waiting for the tree to open

adt1.0.0+ (on behalf of the adt)

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

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

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

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

The 4-10 win2k build gives me an unable to find PNCRT.dll message and then just gives a gray window. I reinstalled, and no joy. But an uninstall and reinstall fixed it, even though the error message still occurs.

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

Adding nsdogfood as this effects many people in house.

Fix checked into trunk and branch

adding branch resolution keyword.

Hey guys, when on a Linux or other Unix box typically root is the user doing the install. Can the installer make certain that the files installed are readable to everyone. I've installed a couple of XULs packaged as .xpi that have included files with read-only permissions to the owner. So, for example, if root was the user that installed the XUL ( which is typical ) then from root's perspective mozilla will work. But all other users will see the blank/grey window.

That has nothing to do with this bug. Currently the XPInstall process preserves the file permissions as seen in the zip archive using info-zip.

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

verified updating 4/2 build to branch and to trunk