Closed
Bug 272982
Opened 20 years ago
Closed 20 years ago
Browser fails to launch (installer build)
Categories
(Firefox :: Installer, defect)
Tracking
()
VERIFIED
FIXED
People
(Reporter: tracy, Assigned: steffen.wilberg)
References
Details
(Keywords: regression, smoketest)
Attachments
(2 files)
37.65 KB,
image/png
|
Details | |
5.06 KB,
patch
|
benjamin
:
review+
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•20 years ago
|
||
Comment 2•20 years ago
|
||
*** Bug 272904 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 3•20 years ago
|
||
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.
Comment 5•20 years ago
|
||
Does it happen with a fresh profile too?
Comment 6•20 years ago
|
||
(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.
Comment 7•20 years ago
|
||
(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.
Might this be related to https://bugzilla.mozilla.org/show_bug.cgi?id=259395
Comment 9•20 years ago
|
||
(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.
Reporter | ||
Comment 10•20 years ago
|
||
The installation is missing xpcom_core.dll Copied it over from 1.0, then the trunk installation launches fine.
Reporter | ||
Comment 11•20 years ago
|
||
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.
Comment 12•20 years ago
|
||
(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)
Reporter | ||
Comment 13•20 years ago
|
||
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
Comment 14•20 years ago
|
||
trunk 2004121307 zip build works ok for me on windows 2000.
Comment 15•20 years ago
|
||
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.
Comment 16•20 years ago
|
||
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.
Reporter | ||
Comment 17•20 years ago
|
||
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.
Comment 18•20 years ago
|
||
*** Bug 274498 has been marked as a duplicate of this bug. ***
Comment 19•20 years ago
|
||
*** Bug 274499 has been marked as a duplicate of this bug. ***
Between which builds did this regress?
Comment 21•20 years ago
|
||
It started with the very first aviary-landing build. I think that was on Dec. 1st.
Comment 22•20 years ago
|
||
(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.
Comment 23•20 years ago
|
||
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.
Assignee | ||
Comment 24•20 years ago
|
||
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.
Assignee | ||
Comment 25•20 years ago
|
||
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)
Updated•20 years ago
|
Attachment #168699 -
Flags: review?(bsmedberg) → review+
Comment 26•20 years ago
|
||
Ben, I think this fixes the installer issues ;)
Comment 27•20 years ago
|
||
I don't quite see how this could fix the installer for other than the en-US version.
Assignee | ||
Comment 28•20 years ago
|
||
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 29•20 years ago
|
||
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)
Reporter | ||
Comment 30•20 years ago
|
||
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 → ---
Comment 31•20 years ago
|
||
This should probably be reassigned to Ben.
Assignee: steffen.wilberg → bugs
Status: REOPENED → NEW
Comment 32•20 years ago
|
||
Where did you get the latest build? It looks to me that the Beast is still building with Steffen Wilberg's last check-in.
Reporter | ||
Comment 33•20 years ago
|
||
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 ago → 20 years ago
Resolution: --- → FIXED
Comment 34•20 years ago
|
||
well in that case, it shouldn't be assigned to Ben...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Updated•20 years ago
|
Assignee: bugs → steffen.wilberg
Status: REOPENED → NEW
Updated•20 years ago
|
Status: NEW → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → FIXED
Comment 35•20 years ago
|
||
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.
Comment 36•20 years ago
|
||
The latest Beast Installer build works great. Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.8a6) Gecko/20041214 Firefox/1.0+
Assignee | ||
Updated•20 years ago
|
Keywords: aviary-landing
Updated•18 years ago
|
QA Contact: bugzilla → installer
Comment 38•18 years ago
|
||
*** 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.
Description
•