This may be a dupe of, or related to, bug 380134. But I'll file it anyway, because it's making finding recent regression ranges on the trunk impossible for me. 1. Download a windows trunk zip build, eg: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2007-05-12-04-trunk/firefox-3.0a5pre.en-US.win32.zip 2. Extract the zip to desktop 3. Navigate into the dir to find firefox.exe, right click on the file and choose 'Create Shortcut'. 4. Right click on the newly created shortcut and choose 'Properties'. 5. At the end of the 'Target' filed, add: -profilemanager 6. OK the shortcut properties dialog. 7. Double-click on the recently-created shortcut to firefox.exe. The profile manager should appear. 8. Make a new profile, and choose to start minefield. Expected: - Browser starts up Actual: - Browser eats 99% CPU time and never starts up (as far as I can see, anyway).

For me, this works with 20070501_0937_firefox-3.0a5pre.en-US.win32.zip (Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a5pre) Gecko/2007050109 Minefield/3.0a5pre) And fails in 20070501_1035_firefox-3.0a5pre.en-US.win32.zip (can't get buildid because it doesn't start) (Builds taken from the hourly archive at http://hourly-archive.localgho.st/ -- times in filename indicate start time of build) Checkins to module PhoenixTinderbox between 2007-05-01 09:00 and 2007-05-01 11:00 http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=+2007-05-01+09&maxdate=+2007-05-01+11&cvsroot=%2Fcvsroot No idea what caused this regression.

Although I think it's likely to be either bug 378038 or bug 378975. So taking the liberty of CC'ng Alex & Boris.

(In reply to comment #2) > Although I think it's likely to be either bug 378038 or bug 378975. So taking > the liberty of CC'ng Alex & Boris. > Steve, do you work with AT? If you don't then it shouldn't regressed from my bug because accessibility won't be activated.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a5pre) Gecko/20070512 Minefield/3.0a5pre ID:2007051206 [cairo] I couldn't reproduce this bug, after creating a new profile FF starts up fine.

Likely a duplicate of bug 380134. Steve, is there history being imported?

Boris, as I am making a new profile as I launch firefox, I assume there is no history at this point to import.

Steve, you're not alone! Try adding the -safe-mode string at the very end of the target command line. I can almost guarantee it will allow you to bypass after choosing 'Continue in Safe Mode'. I didn't check anything on the UI. That was the only way I was able to start the build. This problem is exactly the same as mine except I receive an error message over 'tapi32.dll' and I don't know why I got chosen to be the lucky guy. Read here: http://forums.mozillazine.org/viewtopic.php?p=2879796#2879796 Furthermore, once in safe mode, the build seems to function fine with no ill effects. Confirmed busted w/ Win zip trunk nightlies 3/20 thru 5/11 on XP SP1. Note: The link I provided describes my problem further. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/2007032004 Minefield/3.0a3pre [SAFE MODE] ------------------------------------------- Almost 100% positive this crap started it: #371667 [Core:Networking]-The offline and online WHATWG events do not fire if the network connection goes down on Windows XP [Win] The Official Win32 20070320 [Trunk] build: http://forums.mozillazine.org/viewtopic.php?t=532071

Extra info: tapi32.dll - 5.1.2600.1106 size: 161 KB (xpsp1.020828-1920) Steve, I think you're not getting the error message b/c you're on 2000. And not many nightly users testing on that I don't think. And most if not all XP users are SP2. Those are my standout theories.

I can only reproduce this when there is no Mozilla\Firefox profile present, but only an old Firefox profile with a history.dat in it. In the early months of 2004 the profile was called "Firefox". On startup Minefield will only make a profiles.ini in the Mozilla\Firefox profile that will point to the old Firefox profile and import the history.dat. As long as the old Firefox profile is present Minefield will use that old profile. But I assume if you are using a Firefox profile instead of a Mozilla\Firefox profile you would know and see it.

Does the problem only occur on XP SP1 and/or Windows 2000 installs? I don't have any of these OS's handy to test a build with bug 371667 removed to confirm if that is the problem - can someone try that? If not, I'll try and track down one of those OS's and try it. The patch in Bug 371667 doesn't use TAPI directly but does call RAS routines which may or may not involve TAPI depending on configuration a quick google seems to indicate.

Bizarrely this is now working for me, even though before the problem persisted long enough for me to independently find a regression range identical to bug bug 380134's. Following my repo steps in comment 0 and using the same two builds mentioned in comment 1, so I'm not sure what to do with this bug report. I will certainly keep trying to reproduce this, and maybe I will be able to find additional repo steps that caused this bug to show itself originally.

Well Chris, if you can pump out a build w/ that checkin backed out, I'll test it. Is there like some official server that moz devs or average users can use to host builds w/ backed out checkins? Maybe it's time a build builder be made where you can request it backout a certain checkin and it pumps it out for you, and hosts it for a short time? Easier said than done, I know. Steve, did you install any software recently that may have updated some certain files?

Noah, no, nothing newly installed. And for me the problem has returned again for no reason that I can fathom.

Noah, I'll do a build today with it included and without and post a link here for you to test, thanks!

Noah, try these: http://www.bluishcoder.co.nz/firefox-with-371667.zip http://www.bluishcoder.co.nz/firefox-without-371667.zip This is built from trunk yesterday. The first is the normal trunk build. The second is with the patch reversed. Hopefully this will confirm if that patch is the problem.

Chris, d/l'ed the patchless build and ran it 1st and it wouldn't run... but not for the same reasons. :D Maybe you forgot to include whatever other materials you need to build? Both look pretty light - yours: 7.91 MB < current zip nightlies: 8.69? Anyway, got instant dialog box alerting me: "This application has failed to start b/c the application configuration is incorrect. Reinstalling the application may fix this problem." Grabbed these from Event Viewer (which also led me to think compile problem): • Dependent Assembly Microsoft.VC80.CRT could not be found and Last Error was The referenced assembly is not installed on your system. • Resolve Partial Assembly failed for Microsoft.VC80.CRT. Reference error message: The referenced assembly is not installed on your system. Ah! Yup, missing 4 VC8 files (worth about 1.57 MB). Grabbed them from another nightly, BOTH builds ran fine!?!? This was for sure introduced in 3/20 and crashing all the way til 5/14. Getting the official 5/15 build now to confirm - possibly bug 370195 fixed it or bug 340212? Or by a longshot bug 363089? 5/15 trunk thread: http://forums.mozillazine.org/viewtopic.php?t=549030 ---------------------------------- Prior troubleshooting I tried: http://forums.mozillazine.org/viewtopic.php?p=2880827#2880827 This might or might not help you w/ your online/offline patch: tapi32.dll crashes @ fault address 0x00003fe7 everytime

OK, too much wishful thinking on my part. Those builds you provided gave me a false high as the official 5/15 build sent me crashing back down to earth. :D A weird thing tho about your builds... the patchless build is 1kb larger than the patched build; 1,807 kb > 1,806 kb? Maybe you made 2 patchless builds? If not, you worked some great magic. :D Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a5pre) Gecko/20070515 Minefield/3.0a5pre [SAFE MODE]

Welp I have this problem back Works (Fx starts up with a new profile): - 20070501_0937_firefox-3.0a5pre.en-US.win32 Broken (Fx munches 99% CPU time, does not start up): - 20070501_1035_firefox-3.0a5pre.en-US.win32 - Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a5pre) Gecko/20070515 Minefield/3.0a5pre ID:2007051504 [cairo] - http://www.bluishcoder.co.nz/firefox-with-371667.zip - http://www.bluishcoder.co.nz/firefox-without-371667.zip Also, Noah's regression range (comment 7), and the one I've got (comment 1) are totally different, so aren't these two separate issues?

Once you've made the new profile, does it start up when you use the profile for the second time? If it doesn't that would differ from bug 380134.

Noah, I'm pretty sure that I did the two builds correctly, one with and one without the patch. Just to confirm I've done it again with the latest trunk code from today: http://www.bluishcoder.co.nz/firefox-with-371667-2ndtry.zip http://www.bluishcoder.co.nz/firefox-without-371667-2ndtry.zip These builds were produced using: make -f client.mk build make -C obj-dir/browser/installer That generated the .zip files which I renamed and uploaded. I'm not sure if the nightly builds do anything else - they must do if they include the VC redistributable files.

It looks like you were right. Both work. So your checkin was not to blame. Sorry to doubt you in the 1st place. But I did realize that there may be something different about the way you make your builds than from the official nightlies apart from including VC 8 files. So I remembered the command 'about:buildconfig' and ran it on your build and the official. The official builds for target i686-pc-cygwin. Yours: mingw32. The 'build tools' lines were the same except for $(CYGWIN_WRAPPER) not being in front of each line. Your compiler simply says 'cl'. And under arguments you're missing alot but I'm not sure they're all necessary to begin with: --enable-application=browser --enable-update-channel=nightly --enable-optimize --disable-debug --disable-tests --enable-static --disable-shared --enable-svg --enable-canvas --enable-default-toolkit=cairo-windows --enable-update-packaging You have: --enable-application=browser --enable-optimize --disable-debug --disable-auto-deps --enable-static I'm wanting to help and see if I can backout some other patches from the 3/20 build but I'm not too keen on compiling my own builds. Is it as hard as one would think? Email me a beginner's guide, Chris, if you wouldn't mind. I would like to try to rebuild exactly like the official. ------------------------------------------- I agree with chob aka Steve. ;) My problem was different. At 1st I thought he wasn't getting the error b/c of his OS but now I think it has to do w/ his VC 8 files being outdated. Mine are 8.0.50727.42. But chob's can't be Ria's bug either per his comment.

OK, well for me, the regression range i found in comment 1 still stands. Further, firefox munches on 99% of my CPU for a little under 5 minutes (AlthonXP 2400) before starting up normally. After it starts up, the bookmarks are the default and there is no history except the two starting pages.

After firefox has has taken ~5mins to start up with a new profile, subsequent starts of firefox with the same profile are immediate.

Any idea what's taking up the CPU during that time? Can you try attaching with a debugger or something and seeing what code is running?

Ryan VanderMeulen has been doing me some windows builds (big thanks!) and this problem is definitely caused by bug 378975. (Pre 378975 fx starts up fine for me after making a new profile, post 378975 there's a 4-5 minute wait for fx to start up after making a new profile). Boris, is 'attaching with a debugger' something I can do without having a development environment set up?

I don't really know, to be honest... This really is sounding like bug 380134 one way or another, though...

confirming to get on the radar.

Seth, can you look into this and resolve appropriately?

I think this is a WFM now. [I'm going to test the builds mentioned in comment 2 and in comment 18 to make sure the problem really existed, and then resolve this bug WORKSFORME if no one has any objections]

I still get long startups also. There was one day about two weeks ago that startup was like instantaneous and the whole browser seemed light years faster. I could only reproduce it on my home PC and couldn't figure out what caused it. Next day went back to being slow. Try to reproduce it with the older builds without luck. Still stuck with slow startup times on my work and home laptops.

With all of the recent work around perf/expiration, I haven't see a slow startup in ages. Unless someone has some data, or working STR, I think this is done.