279342 - big history.dat file kills menubar pulldown performance

Status: RESOLVED DUPLICATE of bug 222717

(Firefox :: General, defect)

Description

[Jamie Zawinski]

I know this isn't going to be the clearest bug report, but I'm unable to use
Firefox because of it, so I might as well give it a try...

On my home machine, Fedora Core 3 x86, Firefox often goes catatonic for 5+
seconds at a time.  It does this *most* of the time when I click a link (but not
always).  "Catatonic" means that it is not repainting, and the throbber is not
throbbing.  

Immediately after Firefox starts up, if I click the mouse in the menubar over
the Help menu, hold the mouse down, and drag slowly to the left (popping down
each menu in turn) it will *always* go catatonic for ~5 seconds as soon as the
mouse reaches the "Go" menu.  Subsequent repetitions of this *usually* cause
catatonia, but not always.

The weird thing is, Firefox works just fine on the Fedora Core 3 x86 machine I
have at work; it's only my home machine that exhibits this lossage.  But on that
machine, it's bad enough to make it totally unusable.  (And of course Mozilla
1.7.3 works fine on both machines.)

The Firefox I have is from the FC3 RPM, "firefox-1.0-2.fc3".
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0

I attached a gdb to it and interrupted it at a few points to get backtraces. 
Since that build doesn't have debug info, that's probably not very useful, but
I'll attach it anyway.

Are there more recent builds of Firefox that I should try?  The "nightlies"
directory looks like it only has Mozilla builds?

Comment 1

[Jamie Zawinski]

Attachment: gdb backtraces

Comment 2

[Ben Fowler]

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/

Comment 3

[Jamie Zawinski]

Ok, I see exactly the same problem with
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2005-01-22-07-trunk/firefox-1.0+.en-US.linux-i686.tar.gz

Comment 4

[Jamie Zawinski]

Attachment: backtraces from nightly

Some more backtraces from that nightly build.

Comment 5

[Dan Mosedale (:dmosedale, :dmose)]

I can't reproduce this exactly in a debug build, but if I try, when the mouse
hits the Go menu, the following spits out on stderr: 

JavaScript error: chrome://browser/content/browser.js, line 1213:
history.treeBoxObject.view has no properties

None of the previous menus triggered that.

Comment 6

[Jamie Zawinski]

If I delete firefox/*.default/history.dat it starts behaving properly.

This history.dat file was auto-imported from Mozilla 1.7.3, where 
it works fine.

I have my links set to never expire ("9999 days") and so the file
is currently 22 MB.

Fuck Mork.  Fuck it bad.

Comment 7

[Jamie Zawinski]

This has begun happening again:

  > Immediately after Firefox starts up, if I click the mouse in the
  > menubar over the Help menu, hold the mouse down, and drag slowly to
  > the left (popping down each menu in turn) it will *always* go
  > catatonic for ~5 seconds as soon as the mouse reaches the "Go" menu.

Since it is now almost exactly three months since I reported this bug
(at which time I grudgingly cleared my history) we can conclude that
Firefox's performance craters as soon as there are more than 90 days
worth of pages in the browser history.

Obviously the *right* fix to this is bug 241438, "kill Mork", but
surely some simpler workarounds would be available too.

For example -- whatever it is that you are doing as a result of 
button-down on the menubar -- stop doing that. 

I imagine it has something to do with creating the list of the last
N visited pages on the "Go" menu; that could easily be cached somewhere
instead of descending into ninth circle of Mork to find it.

I like having my link-colors *never* expire; I've been doing it that
was for ten years, and it is very frustrating that Firefox doesn't
let me do that any more.

My history.dat is 22MB.

Comment 8

[Michael Gabriel]

also look at your memory usage and startuptimes. with mozilla and a 30meg
history.dat it also creates a startup lag of 5+ seconds and the memory usage is
much higher. related bug 294332

Comment 9

[miahz]

Ditto Jaime.  I like knowing where i've been.  Ever.  My history.dat is now 135MB and climbing.

Work-around is to hide the Go menu in userChrome.css:

/* Remove the Go menu */ 
menu[label="Go"] {
  display: none !important;
}

This sounds pretty much like Bug 222717, btw.