Steps to reproduce: 1. Accumulate a reasonable amount of bookmarks and history. 2. Start a build with places, such as Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060307 Firefox/1.6a1. Result: It takes about 10 seconds to start up (presumably as it imports bookmarks and history), but there isn't any visible indication of why Firefox is taking so long to start. I know what's going on because I heard about the Places landing, but most users upgrading from Firefox 1.5.0.x to Firefox 2 will not. Expected: Progress window. (Being 10x faster would be nice too, but a progress window would still be needed for people with months of history.)

See Bug 327114 -> Bug 325171 = 37 seconds here for a history.dat file of 3,68 MB and bookmarks.html of 795 KB and 32 extensions.

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

Blocking to reflect need for either a progress window, or a way to make this happen in a way that doesn't block the main UI thread, or similar.

re-targeting to M8.

wip patch

Not blocking on this bug for final ship. Would take a safe enough patch if one comes through.

Mike, that Firefox takes a minute to start up [1], without *any* visible indication that it's alive, is a terrible first-use experience. The user has to assume that something went badly wrong during the upgrade, that Firefox is broken and locked up somehow (looping, deadlock, freaking out on a configuration/pref file, whatever), and it's quite likely that the user will kill it. Given that it's the first time he sees FF3, he can't know that this behaviour is "normal". Any operation that takes more than 2 seconds needs a progress indication. It's not optional. In this case, lacking one is quite often fatal. This bug is a show-stopper. [1] Cited above are 38 seconds. It was several minutes (!) for me.

Tony: can we get someone to do a bit of testing with and representative Firefox 2 profiles that QA has kicking around? Ben/Jesse: what kind of hardware was this on? I take it that this was pause between starting up the app and the main window drawing? I'm surprised we haven't seen it reported more frequently, is all.

This test file took about 5 seconds using the latest nightly: http://www.mozilla.org/quality/browser/front-end/testcases/bookmarks/hugebookmarks.html. Of course, that will differ across hardware capabilities, etc, etc. Fixing Bug 392193 would mitigate this problem. I've started a try-server build with that patch, will show up here: https://build.mozilla.org/tryserver-builds/?C=M;O=D

> Ben/Jesse: what kind of hardware was this on? Fairly powerful machine: Athlon 64 3500+ or better, 2 GB RAM, Linux > I'm surprised we haven't seen it reported more frequently There are many reasons thinkable, for example that not all people have a large set of history/bookmarks/whatever or that they cannot attribute a non-starting (or extremely slow starting) Firefox to bookmarks import.

Ben, see comment 9. Looks like we're testing this, and the timeout isn't that huge. I agree that if we think for common cases it'll be longer than 10s, we need some sort of progress window. That doesn't seem to be the case, though. This bug still makes me nervous, but looks like it doesn't block for now. Tony: you guys are testing migration scenarios with large history and bookmark files, yes?

Try-server build failed due to patch-rot. I'll see if Ondrej can update that patch.

Mike Beltzner wrote: > I agree that if we think for common cases it'll be longer than 10s I think it's a fairly good bet that there are common cases where this takes more than 10s. I don't have the time to prove it, though. It maybe easier to fix the bug than to prove it. All you really need is a window telling what's going on and optionally a progress meter.

(In reply to comment #9) > This test file took about 5 seconds using the latest nightly: > http://www.mozilla.org/quality/browser/front-end/testcases/bookmarks/hugebookmarks.html. > Of course, that will differ across hardware capabilities, etc, etc. This is not a good test file, all the URLs are the same, so there are almost no inserts into moz_places, it would be much slower on the same hardware if you used real bookmarks. I have used my real bookmark collection with 5700+ items and twice as big (1.2MB) and here are the times in the debug build: Original version: 28.7s Patched with bug 392193: 6.6s (In reply to comment #12) > Try-server build failed due to patch-rot. I'll see if Ondrej can update that > patch. I have unrotten the patch already yesterday.

not going to make Fx3.1 at this stage, retargeting 3.2

Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h". In Thunderbird 3.0b, you do that as follows: Tools | Message Filters Make sure the correct account is selected. Click "New" Conditions: Body contains places-to-b-and-h Change the action to "Delete Message". Select "Manually Run" from the dropdown at the top. Click OK. Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter. Gerv

The solution here isn't really a progress window, but rather having import be a faster, asynchronous, background operation. As such, we will not be adding a progress dialog.

Mike, is there a bug filed to do that? If not, then reopen and redefine this one, please.

According to mak, the relevant bug is bug 519514.