Closed Bug 308374 Opened 19 years ago Closed 19 years ago

Firefox 1.5 (beta/RC) silently fails to start on some systems when upgrading from 1.0.x

Categories

(Toolkit :: Application Update, defect)

Product:
Toolkit
Component:
Application Update
Version:
1.8.0 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: aero, Unassigned)

References

(
URL
)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4

On some users' systems, installing Firefox 1.5b1 on top of 1.0.6 will result in
1.5b1 consistantly silently failing to start.

Reproducible: Always

Steps to Reproduce:
1. Install Firefox 1.0.6
2. Use it for a while ;)
3. Install Firefox 1.5b1
Actual Results:  
Firefox 1.5b1 will never start. (Uninstalling 1.5b1 and reinstalling 1.0.6 is
successful.)

Expected Results:  
Firefox 1.5b1 will grace me with its presence :)

I am not the user in the linked thread, however I was experiencing the exact
same problem (as were others I noticed on other forums such as Slashdot and
Digg). I did not post in the thread because I didn't feel like making a
Mozillazine account.

Neither deleting user profiles nor deleting registry keys solves the problem.

Solution #1: Installing Firefox 1.5b1 to a path other than the one 1.0.6 was
installed in is successful and results in 1.5b1 starting normally. However, this
alternate path is not desireable.

Solution #2: Uninstalling Firefox 1.0.6 and completely deleting all files it
leaves behind in the path prior to installing 1.5b1 is also successful and
results in 1.5b1 starting normally. (Note that simply uninstalling is not
sufficient; the uninstaller leaves files behind which cause 1.5b1 to fail.)
However, average non-technical users cannot be expected to perform these extra
steps.

I am aware that this bug does not affect all users. Sorry, but I was unable to
determine which file(s) in the 1.0.6 installation are causing 1.5b1 to fail. It
may interest you to know that I started clean with Firefox 1.0 final, so there
were no pre-1.0 files left on my computer when installing 1.5b1.

My appologies if this is a dupe, I honestly really tried to search and didn't
find anything...
Version: unspecified → 1.5 Branch
I had this bug on 1.5 rc1 when upgrading from 1.0.7. After running the full 1.5 install on Windows XP w/ service pack 2 and all patches, FireFox would not open. I opened task manager, and watched it run for a miniscule (less than a second) amount of time, and close. (GUI never appeared.) So I moved my profile out of the way, and it still did the same thing.

I then uninstalled FireFox, and removed the "Mozilla FireFox" directory. Then I installed 1.5rc1 and everything was fine. I'm guessing it most likely has something to do with a file in the main FireFox directory, as getting rid of the profile directory did not fix the problem. Although, something I slapped my head for later on was that I also didn't fully remove my FireFox Application directory which contained files like: pluginreg.dat and profiles.ini.
(ie: C:\Documents and Settings\XXXX\Application Data\Mozilla\Firefox)

I have a backup of my profile, and of the leftover files in the main directory after uninstalling FireFox. I will attempt to install FireFox 1.0.7 and see if I can recreate this problem, and if I can, I'll report back here. It may just simply be that I haven't done a full FireFox removal cycle from my computer for a few versions and something may have gummed up in one of the previous ones.


OS: Windows XP service pack 2 fully patched.
Extensions I had installed before upgrade:
Web Developer 0.9.4
ColorZilla 0.8.3
ChromEdit 0.1.1.1

I can definitely confirm this bug.

I have a test case, but I was not able to pinpoint what is causing it, though. I tried deleting file after file in my attachment, and it seems like it might be a couple of files causing the problem, or weird conditions. I feel that someone with a debug version of the browser or who knows how to debug the browser could probably figure this out. I did find that if I deleted the components directory in this attachment that I was able to get FireFox 1.5rc1 to start up after install.

I'm attaching my left-over 1.0.7 directory after I uninstalled it. In it you will find the Mozilla directory that normally goes under Program Files in Windows.

Steps to reproduce problem:
-----------------------------
*) Unzip file. In it is the "Mozilla FireFox" directory that was in my Program Files directory after I uninstalled FireFox 1.0.7. Watch out for your current FireFox directory!

*) Install Mozilla FireFox 1.5rc1 over this directory.

The problem should now show itself, and the newly installed FireFox will not run.

Profiles seem to have nothing to do with this problem. Hopefully this attachment is ok to post. Sorry about it being 2.5 megs. I'd use a different compression method besides zip, but wanted to make sure everyone could use this. Hopefully it has no personal information in it. ;)

Turns out I can't upload 2.5 meg attachments. It's over 300K. Here's a link to my Geocities site. I'll leave it up for a month or so.

http://www.geocities.com/joshprogramming/Firefox_left_over_install.zip
Component: General → Software Update
Summary: Firefox 1.5b1 silently fails to start on some systems when upgrading from 1.0.6 → Firefox 1.5 (beta/RC) silently fails to start on some systems when upgrading from 1.0.x
This is a me too.
I have Ffx 1.0.7 on Win2K. 
Ffx 1.5RC3 installs OK but when I launch it nothing happens (no windows / errors) and the process quits after a few secs
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.8.1?
Flags: blocking1.8.0.1?
Does anyone have a copy of the file in comment 3 that I could get? I have a debug Firefox that is just waiting to break itself on some files, but the GeoCities account has gone over its bandwidth allocation :(
Here, I should've just copied it over here in the first place. (Dang geocities.) Sorry about the waste of time. I'll keep it up here for a month or so.

http://www.infogears.com/downloads/tmp/Firefox_left_over_install.zip

(In reply to comment #5)
> Does anyone have a copy of the file in comment 3 that I could get? I have a
> debug Firefox that is just waiting to break itself on some files, but the
> GeoCities account has gone over its bandwidth allocation :(
> 


There is another guy at mozillaZine that has experienced this problem. I left a note there for him to come here and leave a note about it, but in case he doesn't, there are a couple of details in his post there.

http://www.mozillazine.org/talkback.html?article=7704#15
I have some good news and some bad news.

Good: installing Firefox 1.5RC3 on top of that zip makes it fail to start.
Bad: installing my debug build on top of that zip starts fine.

The Firefox console.log (in %AppData%\Mozilla\Firefox), which is a new feature for 1.5, is not getting a single thing sent to it either, which suggests a very early failure. In fact, I am suspecting a missing symbol somewhere.

Seeing what I can extract from depends and windbg, but it's slow...
Alright, solution!

To fix any build in this situation, do this:
  1. Make sure you're logged in with full permissions on the install folder.
  2. Delete all components\*.xpt files EXCEPT browser.xpt.
  3. Delete compreg.dat.
  4. Make sure .autoreg exists in the firefox.exe folder.
  5. Start Firefox.

Now, the problem is relatively simple - the components directory has the contents of a non-static Firefox build [1] in it. I don't know for sure if mozilla.org ever released such a build, but I'm willing to bet most other builds are non-static (all builds were this by default until very recently).

Interestingly, though, all the XPTs are dated 9th Nov 2004, which *is* when Firefox 1.0 was originally released.

So, I have a question for everyone with this problem: did you ever install a version that was not an official mozilla.org release?

[1] In a static build, all the XPT files are bunched in to one (browser.xpt), rather than having lots of little ones with different names.
I did. I think I installed a "MOOX :: Optimized Firefox Builds" build a long time back. I'm surprised I didn't wipe the directory when switching back to main line, but it's possible I installed right over.

Is this something that can be accounted for by the installer, or will changing that cause problems?

(In reply to comment #9)
> So, I have a question for everyone with this problem: did you ever install a
> version that was not an official mozilla.org release?


(In reply to comment #9)
> Interestingly, though, all the XPTs are dated 9th Nov 2004, which *is* when
> Firefox 1.0 was originally released.

Just to clear this up a bit - the official mozilla.org Mozilla Firefox 1.0 en-US release had XPT files dated 7th Nov 2004, so the ones in the zip must be from a different build.

(In reply to comment #10)
> Is this something that can be accounted for by the installer, or will changing
> that cause problems?

It's a tricky problem to solve, as there is no easy way to know which XPTs are core and which may have been placed by plugins/extensions/random things. This is why the installer will leave files, because it doesn't know who they belong to.
Josh Rosenbaum's problem is an INVALID bug, you just can't mix builds from different vendors in the same directory. (or Mozilla zip releases and installer releases, a zip release will also have all those .xpt files). Different packaging and different build options lead to instability.

It probably worked as long as you stayed on the 1.0 branch because the interfaces described by the .xpt files remained unchanged. When you upgraded to 1.5 some of the older .xpt files won out and described the wrong version of some crucial interface, killing the browser.

Was the original aero@aeroleviathan.com problem the same thing? What are the odds he installed over a MOOX or zip build as well?

Since we know people do in fact install over zip builds we could teach the installer about all the extra .xpt files and remove them. Might not help against installing over arbitrary non-Mozilla builds though, and it's possible some legitimate addon might reuse some of the same names. These days most of those things are installed under Extensions rather than components, though.
My sincere appologies. I did indeed have a MOOX build at one point... I don't know how I didn't think of that. Obviously this is not something an 'average, non-technical' user would do, so I guess this bug is moot.

Thank you all for your help. Firefox 4evah! And stuff.

Oh, you might want to put something about this issue in some kinda FAQ, or something, for technically-oriented users to find? Just a thought.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → INVALID
Thanks for the quick work on this guys. You're doing a great job.

Perhaps when FireFox uninstalls it should give an option to remove the FireFox directory in Program Files if there are left-overs?
Chris Biechlin <cbeak@cox.net> writes:

I was unable to post to the page that you had posted to on bugzilla but...

Solution II.
 
I deleted all the .xpt files except for the browser.xpt file and deleted the compreg.dat. and ensured that the .autoreg existed. When I tried to start the Browser it failed, but lasted just a bit longer in the Task Manager than it had. I read what was said about Moox, and remembered that I had also used that at one time. I deleted that directory and still it wouldn't start BUT it would start in the "Safe Mode." After starting in the safe mode I was then able to start it in the Normal mode. I had a couple of plugins that are no longer viable apparently. One being the bandwidth tester and another being a session saver (which I had grown to dislike, so no loss there). So ... the good news is that it is working fine now... hope this helps others.
I was moving from 1.07. My XPSP@ machine had no problems. My XP machine had the problem discussed. Deleting the xpt files and compreg.dat, etc. as per the previous post did not work. Instead I ended up deleting the folder under the Program Files (directory folder) and then reinstalling. Now it runs. I did not have to delete my profile folder or any level above with my user folder, except I had already deleted the compred file. I did not have a previous non-Moz version installed. Thanks for the assistance to get me started.




(In reply to comment #15)
> Chris Biechlin <cbeak@cox.net> writes:
> I was unable to post to the page that you had posted to on bugzilla but...
> Solution II.
> I deleted all the .xpt files except for the browser.xpt file and deleted the
> compreg.dat. and ensured that the .autoreg existed. When I tried to start the
> Browser it failed, but lasted just a bit longer in the Task Manager than it
> had. I read what was said about Moox, and remembered that I had also used that
> at one time. I deleted that directory and still it wouldn't start BUT it would
> start in the "Safe Mode." After starting in the safe mode I was then able to
> start it in the Normal mode. I had a couple of plugins that are no longer
> viable apparently. One being the bandwidth tester and another being a session
> saver (which I had grown to dislike, so no loss there). So ... the good news is
> that it is working fine now... hope this helps others.

(In reply to comment #15)
> Chris Biechlin <cbeak@cox.net> writes:
> I was unable to post to the page that you had posted to on bugzilla but...
> Solution II.
> I deleted all the .xpt files except for the browser.xpt file and deleted the
> compreg.dat. and ensured that the .autoreg existed. When I tried to start the
> Browser it failed, but lasted just a bit longer in the Task Manager than it
> had. I read what was said about Moox, and remembered that I had also used that
> at one time. I deleted that directory and still it wouldn't start BUT it would
> start in the "Safe Mode." After starting in the safe mode I was then able to
> start it in the Normal mode. I had a couple of plugins that are no longer
> viable apparently. One being the bandwidth tester and another being a session
> saver (which I had grown to dislike, so no loss there). So ... the good news is
> that it is working fine now... hope this helps others.
Flags: blocking1.8.1?
Flags: blocking1.8.0.1?
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.