Closed Bug 272982 Opened 20 years ago Closed 20 years ago

Browser fails to launch (installer build)

Categories

(Firefox :: Installer, defect)

x86
All
defect
Not set
blocker

Tracking

()

VERIFIED FIXED

People

(Reporter: tracy, Assigned: steffen.wilberg)

References

Details

(Keywords: regression, smoketest)

Attachments

(2 files)

seen with Firefox trunk build 2004-12-03-08-trunk

(tested using the installer)
-Upon installation completing alow FF to launch

tested results:
a small window appears with window id="main-window" (screen shot to follow)

expected results:  
FF browser launched

note: this does not affect todays Mac trunk build. Nor does it affect the
Corresponding Windows .zip build.
*** Bug 272904 has been marked as a duplicate of this bug. ***
affects linux installer but not the full package.
OS: Windows XP → All
I having been getting the same thing for a couple of days now. The only
difference is the window that pops up says DIALOG in it. The installer build
refuses to run.
Does it happen with a fresh profile too?
(In reply to comment #5)
> Does it happen with a fresh profile too?

Got the identical <window id="main-window" dialog.
Previous version, 20041130, deleted with Add/Remove.  Program Files\Mozilla
Firefox directory removed.  Mozilla directory under Windows directory removed. 
Under C:\Windows, mosver.dat deleted and UninstallFirefox.exe deleted. Deleted
all mozilla firefox entries from the Windows Registry. Windows\Temp directory
was empty. Ran RegClean, followed by Scandisk, defrag and a reboot prior to
installing build 20041205. I am running Win 95 OSR2.
(In reply to comment #6)
> (In reply to comment #5)
> > Does it happen with a fresh profile too?
> 
> Got the identical <window id="main-window" dialog.
> Previous version, 20041130, deleted with Add/Remove.  Program Files\Mozilla
> Firefox directory removed.  Mozilla directory under Windows directory removed. 
> Under C:\Windows, mosver.dat deleted and UninstallFirefox.exe deleted. Deleted
> all mozilla firefox entries from the Windows Registry. Windows\Temp directory
> was empty. Ran RegClean, followed by Scandisk, defrag and a reboot prior to
> installing build 20041205. I am running Win 95 OSR2.

I can reproduce on a fresh install on Windows XP SP2. I don't know if this plays
into it, but I'm also seeing Bug 272985 and wonder if the problem is related to
not being able to get through the import settings wizard.
(In reply to comment #8)
> Might this be related to https://bugzilla.mozilla.org/show_bug.cgi?id=259395

Since that bug is closed WFM, and this bug is known to be caused by the aviary
landing, no.
The installation is missing xpcom_core.dll 
Copied it over from 1.0, then the trunk installation launches fine.
Retract my last comment.  Having both 1.0 and the trunk installed, although in
different dirs, fooled the system and me. I cleaned up both installations, then
reinstalled the trunk.  The xpcom_core.dll is there this time.

more investigation needed.  
(In reply to comment #10)
> The installation is missing xpcom_core.dll 
> Copied it over from 1.0, then the trunk installation launches fine.

I don't have xpcom_core.dll in Firefox 1.0 directory but I have it in trunk
installation directory.

with 2004-12-09-07-trunk installed, Firefox even failed to show the small window.
(installer with 09-Dec-2004 16:31 timestamp)

morphing---

This now encompasses zip builds as well.  Firefox trunk builds no longer launch
with the zippy or the installer.  The installer attempts to launch for about two
seconds then fails silently.  The .zip build endlessly attempts to launch
without success.  I watched the Windows task manager; firefox.exe would come and
go and jump around the list.  It's process couldn't be ended.  Also, under
performance, CPU usage is pegged out at 100%
Keywords: regression
trunk 2004121307 zip build works ok for me on windows 2000.
re comment #13.  I had the same problem yesterday.  My problem was caused by
doing debugging on bug 273423.  Since this is one of your bugs, perhaps you ran
into the same issue.  Switching back and forth between en-US and en-GB builds
messed up my profile in such a way that some versions of firefox would get into
a loop upon launch.  Creating a fresh profile fixed my problem yesterday and I
was able to install and launch today's windows zip build (Mozilla/5.0 (Windows;
U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20041213 Firefox/1.0+) without
problems and without having to build a new profile today.

In any case if there is a problem with launching zip builds I think it would be
better to create a new bug, because although the symptoms might be similar it is
unlikely that both issues ahve the same cause.
Hrm.  If the process couldn't be ended, were you seeing multiple PIDs?  I
remember something along those lines before 0.9 with the app-restart code.  If
this is that whole "child process fails and does app-restart" bug resurfacing,
its probably related to the extension manager.
I usually run a clean installation; unistall previous build, delete the Firefox
profile folder.  I just ran a search on my system for anything firefox and found
several misc. things laying around.  So I deleted everything I felt shouldn't be
there.  Then retried the .zip and it launched as expected; migration dialog then
app launch.  I then cleaned out that installation and tried the installer
without success.  This remains a smoketest blocker.

Note: the installer is creating a new profile dir and within it a default profile.
*** Bug 274498 has been marked as a duplicate of this bug. ***
*** Bug 274499 has been marked as a duplicate of this bug. ***
Between which builds did this regress?
It started with the very first aviary-landing build.  I think that was on Dec. 1st.
(In reply to comment #20)
> Between which builds did this regress?

There have been multiple bugs post-aviary-landing that made it impossible to
either finish the installer, or launch the browser post-installer.  So it would
be hard to say when this particular issue regressed beyond 'beginning 12/1 with
the aviary landing'.

Immediately after the landing, there were at least 2 bugs that made it
impossible to even finish the installation and get to this point of trying (and
failing) to launch the browser.
re comment #20.  Despite the fact that there were many issues that prevented the
installer from running to completion, this post
http://forums.mozillazine.org/viewtopic.php?&p=1018701#1018701 would tend to
indicate that this issue existed since the initial aviary landing.
Zip builds work fine for me.

The installer doesn't register locales correctly. Replacing installed-chrome.txt
by the one in dist/bin/chrome, and deleting chrome.rdf (the one in the
appdir/chrome), so that it gets recreated from installed-chrome.txt, fixes this.
Attached patch patchSplinter Review
This is a follow-up to this checkin:
http://bonsai.mozilla.org/cvsquery.cgi?date=explicit&mindate=2004-12-02+11%3A31&maxdate=2004-12-02+11%3A31
Assignee: bugs → steffen.wilberg
Status: NEW → ASSIGNED
Attachment #168699 - Flags: review?(bsmedberg)
Attachment #168699 - Flags: review?(bsmedberg) → review+
Ben, I think this fixes the installer issues ;)
I don't quite see how this could fix the installer for other than the en-US version.
Checking in mozilla/browser/installer/unix/ab-CD.jst;
/cvsroot/mozilla/browser/installer/unix/ab-CD.jst,v  <--  ab-CD.jst
new revision: 1.3; previous revision: 1.2
done
Checking in mozilla/browser/installer/windows/ab-CD.jst;
/cvsroot/mozilla/browser/installer/windows/ab-CD.jst,v  <--  ab-CD.jst
new revision: 1.3; previous revision: 1.2
done

Marking fixed.

comment 27: which versions are you talking about? There are no localized trunk
builds yet.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
comment 28:  Well I am not at all sure what the l10n builds that the build
systems are currently producing are.  There seem to be indicators both ways.

1.  The builds are in the latest-0.11-l10n and not the latest-trunk-l10n
directory (which would lead you to believe they are branch builds)

2.  The en-GB build does not exhibit Bug 273423 (which would lead you to beleive
they are branch builds)

3.  Yet the en-GB build I downloaded to see if bug 273423 was present in the
en-GB version has a build identifier of (Windows; U; Windows NT 5.1; en-GB;
rv:1.8a6) Gecko/20041211 Firefox/1.0+ (which would lead you to believe it is a
trunk build)
Reopened.

The problem of app launch failing silently has been fixed.  But the installer
builds are now back to failing as originally described in this bug.  see
comments 0 and 1. It happens with existing profile and clean install.

Status: RESOLVED → REOPENED
Resolution: FIXED → ---
This should probably be reassigned to Ben.
Assignee: steffen.wilberg → bugs
Status: REOPENED → NEW
Where did you get the latest build?  It looks to me that the Beast is still
building with Steffen Wilberg's last check-in.
http://207.200.85.49/pub/mozilla.org/firefox/nightly/2004-12-14-07-trunk/

Sorry about that. His checkin wouldn't have made these builds.  I'll remark fix
pending verification of the fix.
Status: NEW → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → FIXED
well in that case, it shouldn't be assigned to Ben...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee: bugs → steffen.wilberg
Status: REOPENED → NEW
Status: NEW → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → FIXED
Using the first beast tinderbox build from after the checkin, this does seem to
be fixed. I'll leave someone else to confirm that and mark this verified.
The latest Beast Installer build works great.
Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.8a6) Gecko/20041214 Firefox/1.0+
Keywords: aviary-landing
verified with Fx 2004-12-15-08-trunk
Status: RESOLVED → VERIFIED
QA Contact: bugzilla → installer
*** Bug 267121 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: