Closed Bug 222717 Opened 17 years ago Closed 13 years ago

Opening "Go" (a.k.a "History") menu hangs Firefox for many seconds when history is large

Categories

(Firefox :: Menus, defect)

defect
Not set

Tracking

()

VERIFIED DUPLICATE of bug 385397

People

(Reporter: mail, Unassigned)

References

Details

(Keywords: perf)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 Firebird/0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 Firebird/0.7

The "go" menu is inoperable. When clicking on it, Firebird freezes and shows no
reaction to clicking ANY components. After a few seconds, clicking the closebox
results in the Windows "Diese Anwendung reagiert nicht" (German W2k version,
this means "This application doesn't respond"). Windows taskmanager says "Keine
Rückmeldung" (="no response") for the Firebird entry. It's possible to end
Firebird with the "Sofort beenden" (Shutdown now) button and restart.

Hovering the mouse cursor above the menu title gives the 3-D-Button-Effect of
all menu titles. Clicking there (the other menus work) freezes Firebird. Had
that already in version 0.6.

Reproducible: Always

Steps to Reproduce:
1. Start Forebird
2. Click "Go" menu



Actual Results:  
Firebird freezes.

Expected Results:  
Open the "Go" menu.
I can't verify this behaviour on neither a 0.7 release build nor a self-compiled
build from 2003-10-19. Both running under WinXP. Please reinstall and test with
a fresh profile (instructions can be found in English on
texturizer.net/firebird/faq.html#profilemanager or in German on
http://firebird.bric.de/index.php?page=faq#q1.11 )
Meanwhile I narrowed it down. After clicking to "Go" menu title and leaving the
room for some other business, then returning minutes later, the menu had
appeared. Perhaps a relation to the history settings (currently 60 days)?
I see the same thing happening with Firebird on Linux:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030909 Firebird/0.6.1+

Reproducable always, even right after starting up, and with previous versions
of Firebird I've tried. Like Philipp I have my history set very high (180
days). My history.dat file is about 12 megs.

After clicking on Go, Firebird will sit there unresponsive in all windows for
about 50 seconds and then the menu finally comes up and I can do things again.
Most irksome is I never want the 'Go' menu, it is usually me missing
'Bookmarks'.

I've got a strace of this happening if it will help. I framed the event with
'kill -CONT $mozpid', so the strace is just of the actually problem. 'wc -l'
says 7567 lines, 'grep -c ^brk' says 5510 occurances. Watching the trace live,
the brk() calls are dominating the output while Firebird is slow.


(Bugzilla won't let me change the OS from Windows to all.)
Adjusting summary and changing OS.
Eli, if you can confirm that on a current build I will mark this as NEW.
OS: Windows 2000 → All
Summary: Clicking the "go" Menu title freezes Firebird immediately → Clicking Go-Menu hangs Firebird for a long time-period when a large history is present
Does this still happen with a current build from
ftp.mozilla.org/pub/mozilla.org/firebird/nightly/
I can confirm this for
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031216
Firebird/0.7+

Haven't tried any new builds, sorry.

Firebird freezes for more than 4 minutes.  I have a large history file.
*** Bug 232772 has been marked as a duplicate of this bug. ***
Blocks: 223476
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: perf
I've been using pre 0.8 builds recently.  The latest (30th?  28th?) has this
problem, so I tried the latest trunk build (30th IIRC), also has the issue. 
Changed back to Jan 2 pre 0.8, also has this problem.

In short, all builds I've tried it with have the problem :)
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7a) Gecko/20040126 Firebird/0.8.0+
(.:MrC:.)

I have a seven-day history, and sometimes when I open the Go menu it hesitates
for approx. 3/4 to a whole second. I've changed my history to 15 days and will
report back if it slows down further.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040220
Firefox/0.8.0+

Sorry if this isn't related to fixing the bug.

I got tired of accidently selecting (or expanding) the 'Go' menu so I removed it.

Add this to userChrome.css


/* Remove the Go menu */ 

menu[label="Go"]
{
	display: none !important;
}
I get this on 0.8 20040206 on WinXP as well.  It hangs for about 10 seconds for
me.  The CPU usage is 100% all firefox during this time.  No HD usage.  After
clearing the history there's no delay.  Definitely sounds like it's looping over
the history badly when filling up the menu.  (Perhaps doing an unnecessary
sort?)  Now that I've cleared my history I can't confirm whether the same
problem occurs when opening the history sidebar.
After fooling around for a while with the settings I mentioned earlier, I
haven't noticed any real major slowdowns using the Go menu in the latest
post-0.8 trunk builds. All I've seen is a shot one-second delay when opening the
Go menu, but that hardly counts as a long hang IMHO.

Removing self from CC list.
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20041017
Firefox/1.0 (MOOX M3)

I've been having the issue on the past 4 or 5 nightlies.
*** Bug 268774 has been marked as a duplicate of this bug. ***
Summary: Clicking Go-Menu hangs Firebird for a long time-period when a large history is present → Opening Go menu hangs Firefox for many seconds when history is large
I'm experiencing the same thing.  My history retention time is 365 days and the
history file is over 10 MB.

And yes - you don't even have to select the Go button - just mousing over it
sometimes causes this delay.

Also - it only happens once (or maybe a couple of times - not sure) per day -
not every time the button is accessed.

How does Firefox decide when to expire old entries from the History cache? 
Could this be what is causing these infrequent, large delays?  If so, and this
operation cannot be optimized better to be less noticable, then maybe expire old
entries only on startup instead of periodically during a session?
(In reply to comment #15)
> I'm experiencing the same thing.  My history retention time is 365 days and the
> history file is over 10 MB.
> 
> And yes - you don't even have to select the Go button - just mousing over it
> sometimes causes this delay.
> 
> Also - it only happens once (or maybe a couple of times - not sure) per day -
> not every time the button is accessed.
> 
> How does Firefox decide when to expire old entries from the History cache? 
> Could this be what is causing these infrequent, large delays?  If so, and this
> operation cannot be optimized better to be less noticable, then maybe expire old
> entries only on startup instead of periodically during a session?

----------

I am using Firefox 1.0 and Trying to use the GO button hangs
the browser completely -- forced to try and close the window
which pulls up the "Program Not Responding" dialog in Win2K and WinXp
both.

ACK
I have the same problem under Windows XP.  I never close Firefox, usually have 5
windows open with 10 tabs each, and history set to 90 days.  The Go menu will
freeze firefox for about 10-15 seconds (2.4 GHz p4) when I accidentely mouse
over it (I never use it, as far as I'm concerned the entire menu option can be
removed as it is just there to annoy me).

Using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107
Firefox/1.0.

It seems to me to be a general problem with Lists in Firefox; slowness with list
handling is also seen in the download window (I have mine set to remove
downloads on exit, which RARELY happens).  When there's 1000+ files in the
download window, clicking "clean up" can also take ages.
Reproducible with Firefox 1.1
(In reply to comment #18)
> Reproducible with Firefox 1.1

Correction: Reproducible with Firefox 1.0.1
                                        ^^^
Same problem here (still with deer park alpha 1)
I'm used to have a large history (999 days) and therefore "Go" button took about
5 seconds till I cleaned the history up today (but I like to have some hisotry-data)
Now it's fast without history data. Some structure/extra-cache files for the
latest history-data would be nice here... Or some other data-structure in
general for history data, because sorting the history is also very slow for
something that contains only thousands and not millions of data entries. There
should be some better index structure.
*** Bug 295688 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary1.1?
295688 isn't just a duplicate of this, that bug also mentions the shorter but
much more annoying delay that happens every time you visit a new page, after
having used Go.
need to wait on the new unified storage backend to fix this.  mork sucks with
huge datasets, so we have to replace mork.
Flags: blocking-aviary1.1? → blocking-aviary1.1-
*** Bug 297805 has been marked as a duplicate of this bug. ***
wow .. when i change history to 20 day's .. the go button works oke ...
Assignee: firefox → nobody
QA Contact: bugzilla → menus
Hardware: PC → All
Version: unspecified → Trunk
Depends on: 245745
*** Bug 315456 has been marked as a duplicate of this bug. ***
*** Bug 315435 has been marked as a duplicate of this bug. ***
This also happens on the Firefox 1.5 RC2 for Mac. This bug has existed for two years. Has any progress been made? 
*** Bug 318145 has been marked as a duplicate of this bug. ***
*** Bug 321828 has been marked as a duplicate of this bug. ***
*** Bug 324618 has been marked as a duplicate of this bug. ***
In current Firefox 2.0 alpha nightly builds, the Go menu has been changed to the history menu and displays the session history for the current tab. This should always be fast becauses it uses the in-memory and much smaller session history infrastructure. It may be changed to be global history again, but any slowness in that would have very different causes than the Firefox 1.x infrastructure this bug refers to. If you find the Go/History menu is found to be slow in current nightlies, please file a new bug under the Firefox/Places component.
*** Bug 343376 has been marked as a duplicate of this bug. ***
*** Bug 355852 has been marked as a duplicate of this bug. ***
*** Bug 285885 has been marked as a duplicate of this bug. ***
Summary: Opening Go menu hangs Firefox for many seconds when history is large → Opening "Go" (a.k.a "History") menu hangs Firefox for many seconds when history is large
(In reply to comment #32)
It is still slow for me. I have not cleared the history for a couple of months and I use Firefox a lot (so I have built up a large history), which has led to a 15 second delay for the menu to come up and for me to be able to do anything else. No other applications were running when I timed it and I'm using the newest version of Firefox 2.0 with Mac OS 10.4.8. I have a fast computer, so the same problem might be a lot slower for other people. 
Clicking the history menu for the first time in a browser session causes the browser to hang.  I just restarted and reproduced the bug to time it.  It hung for 41 seconds.  Based on my memory of the other times this happened, 41 seconds seems like a reasonable average time.  As best I can tell, this only happens the first time the history menu is clicked in a session.

I am using Firefox 2.0 on Win XP Pro.
I have the history set to 999 days.
Dell 870 with a 3.4GHz Xeon processor, 3G of RAM, nothing else taking CPU time
Reproducible: Always
Duplicate of this bug: 279342
Duplicate of this bug: 375904
OK..after reading this thread, I reproduced what was reported here, and in the bug I reported that has been combined with this one.

In fact, yes, after about 40 seconds, the History Menu DOES come up - and this DOES happen only the first time in a session you click for History.  Any other time, it comes right up.

I'm running Windows 98SE, and using Firefox 2.0.0.3 the most recent nightly build, as I just updated my Firefox yesterday.

I don't recall this happening on older versions of Firefox.

Then again, as someone else pointed out above, usually, it is NOT the History button I want when it gets clicked....it's me missing the Bookmarks Tab.

However, since it only happens first time in a session...and only hangs, does not FREEZE as I had thought it was doing, I suppose I could live with it, but it would sure be interesting to find out what causes this and get some resolution.

All that said, even with this bug, annoying as it is...Firefox beats Internet Exploder 7 any day of the week!
A next reference: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=222107
(Clicking ``GoTo'' item freezes firefox)

There's a bactrace:

qinglong@Bolizm:~> nice -n 18 firefox -g -safe-mode
/usr/lib/firefox-1.5.0.10/run-mozilla.sh -g /usr/lib/firefox-1.5.0.10/firefox-bin -UILocale ru -safe-mode
MOZILLA_FIVE_HOME=/usr/lib/firefox-1.5.0.10
  LD_LIBRARY_PATH=/usr/lib/firefox-1.5.0.10:/usr/lib/firefox-1.5.0.10/plugins:/usr/lib/mre/mre-1.5.0.10
DISPLAY=:0.0
FONTCONFIG_PATH=/etc/fonts:/usr/lib/firefox-1.5.0.10/res/Xft
DYLD_LIBRARY_PATH=/usr/lib/firefox-1.5.0.10:/usr/lib/mre/mre-1.5.0.10
     LIBRARY_PATH=/usr/lib/firefox-1.5.0.10:/usr/lib/firefox-1.5.0.10/components:/usr/lib/mre/mre-1.5.0.10
       SHLIB_PATH=/usr/lib/firefox-1.5.0.10:/usr/lib/mre/mre-1.5.0.10
          LIBPATH=/usr/lib/firefox-1.5.0.10:/usr/lib/mre/mre-1.5.0.10
       ADDON_PATH=/usr/lib/firefox-1.5.0.10
      MOZ_PROGRAM=/usr/lib/firefox-1.5.0.10/firefox-bin
      MOZ_TOOLKIT=
        moz_debug=1
     moz_debugger=
which: no ddd in (/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11/R6/bin:/usr/libexec/sgml-tools)
/usr/bin/gdb /usr/lib/firefox-1.5.0.10/firefox-bin -x /tmp/mozargs.X32071
GNU gdb Red Hat Linux (6.5-15.fc6rh)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) run -safe-mode
Starting program: /usr/lib/firefox-1.5.0.10/firefox-bin -safe-mode
[Thread debugging using libthread_db enabled]
[New Thread -1208383792 (LWP 32074)]
[New Thread -1211008112 (LWP 32077)]
[New Thread -1221608560 (LWP 32078)]
[New Thread -1232528496 (LWP 32079)]
[New Thread -1243018352 (LWP 32080)]
[New Thread -1254098032 (LWP 32081)]
[New Thread -1264587888 (LWP 32082)]
[Thread -1264587888 (LWP 32082) exited]
[Thread -1254098032 (LWP 32081) exited]
[Thread -1232528496 (LWP 32079) exited]
[Thread -1243018352 (LWP 32080) exited]
bt

Program received signal SIGINT, Interrupt.
[Switching to Thread -1208383792 (LWP 32074)]
nsTreeRows::Subtree::InsertRowAt (this=0x9435388, aMatch=0xef4fad0, 
    aIndex=43720) at nsTreeRows.cpp:258
258         for ( ; --aIndex >= 0; ++rowIndex) {
(gdb) bt
#0  nsTreeRows::Subtree::InsertRowAt (this=0x9435388, aMatch=0xef4fad0, 
    aIndex=43720) at nsTreeRows.cpp:258
#1  0x0248c78a in nsTreeRows::InsertRowAt (this=0x9435388, aMatch=0xef4fad0, 
    aSubtree=0x9435388, aChildIndex=119497) at nsTreeRows.h:404
#2  0x02488817 in nsXULTreeBuilder::OpenSubtreeOf (this=0x9435290, 
    aSubtree=0x9435388, aIndex=-1, aContainer=0x964e418, aDelta=0xbfcce3e8)
    at nsXULTreeBuilder.cpp:1649
#3  0x02488b16 in nsXULTreeBuilder::OpenContainer (this=0x9435290, aIndex=-1, 
    aContainer=0x964e418) at nsXULTreeBuilder.cpp:1545
#4  0x0248b8aa in nsXULTreeBuilder::RebuildAll (this=0x9435290)
    at nsXULTreeBuilder.cpp:1365
#5  0x02495b79 in nsXULTemplateBuilder::Rebuild (this=0x9435290)
    at nsXULTemplateBuilder.cpp:245
#6  0x0248c356 in nsXULTreeBuilder::SetTree (this=0x9435290, tree=0xd2e49f0)
    at nsXULTreeBuilder.cpp:835
#7  0x0246a9c1 in nsTreeBodyFrame::SetView (this=0x10176c80, aView=0x9435378)
    at nsTreeBodyFrame.cpp:528
#8  0x02467f6c in nsTreeBodyFrame::EnsureView (this=0x10176c80)
    at nsTreeBodyFrame.cpp:419
#9  0x02468aba in nsTreeBodyFrame::GetView (this=0x10176c80, aView=0xbfcce910)
    at nsTreeBodyFrame.cpp:476
#10 0x0246c214 in nsTreeBoxObject::GetView (this=0xd2e49f0, aView=0xbfcce910)
    at nsTreeBoxObject.cpp:189
#11 0x4d295c41 in XPTC_InvokeByIndex ()
    at dist/include/xpcom/xptcstubsdef.inc:251
#12 0x0048addb in XPCWrappedNative::CallMethod (ccx=@0xbfccea5c, 
    mode=XPCWrappedNative::CALL_GETTER) at xpcwrappednative.cpp:2156
#13 0x0048ffae in XPCWrappedNative::GetAttribute (ccx=@0xbfccea5c)
    at xpcprivate.h:1963
#14 0x0048e9ef in XPC_WN_GetterSetter (cx=0x910e2c8, obj=0x952b200, argc=0, 
    argv=0xb4da628, vp=0xbfcceb7c) at xpcwrappednativejsops.cpp:1483
#15 0x4ce1ca2b in js_Invoke (cx=0x910e2c8, argc=0, flags=2) at jsinterp.c:1187
#16 0x4ce28535 in js_InternalInvoke (cx=0x910e2c8, obj=0x952b200, 
    fval=156414616, flags=2, argc=0, argv=0x0, rval=0xbfcceee8)
    at jsinterp.c:1284
#17 0x4ce286d5 in js_InternalGetOrSet (cx=0x910e2c8, obj=0x952b200, 
    id=150517184, fval=156414616, mode=JSACC_READ, argc=0, argv=0x0, 
    rval=0xbfcceee8) at jsinterp.c:1354
#18 0x4ce2eb65 in js_NativeGet (cx=0x910e2c8, obj=0x952b200, pobj=0x952b200, 
    sprop=0x96216e0, vp=0xbfcceee8) at jsobj.c:3069
#19 0x4ce302c1 in js_GetProperty (cx=0x910e2c8, obj=0x952b200, 
    id=<value optimized out>, vp=0xbfcceee8) at jsobj.c:3210
#20 0x4ce22dc4 in js_Interpret (cx=0x910e2c8, pc=0x94cb134 "5", 
    result=0xbfccefe8) at jsinterp.c:3434
#21 0x4ce1ca84 in js_Invoke (cx=0x910e2c8, argc=0, flags=2) at jsinterp.c:1207
#22 0x4ce28535 in js_InternalInvoke (cx=0x910e2c8, obj=0x90e8320, 
    fval=151134256, flags=2, argc=0, argv=0x0, rval=0xbfccf318)
    at jsinterp.c:1284
#23 0x4ce286d5 in js_InternalGetOrSet (cx=0x910e2c8, obj=0x90e8320, 
    id=150517184, fval=151134256, mode=JSACC_READ, argc=0, argv=0x0, 
    rval=0xbfccf318) at jsinterp.c:1354
#24 0x4ce2eb65 in js_NativeGet (cx=0x910e2c8, obj=0x90e8320, pobj=0x9022020, 
    sprop=0x9277acc, vp=0xbfccf318) at jsobj.c:3069
#25 0x4ce302c1 in js_GetProperty (cx=0x910e2c8, obj=0x90e8320, 
    id=<value optimized out>, vp=0xbfccf318) at jsobj.c:3210
#26 0x4ce22dc4 in js_Interpret (cx=0x910e2c8, pc=0x9403e92 "5", 
    result=0xbfccf418) at jsinterp.c:3434
#27 0x4ce1ca84 in js_Invoke (cx=0x910e2c8, argc=1, flags=2) at jsinterp.c:1207
#28 0x4ce28535 in js_InternalInvoke (cx=0x910e2c8, obj=0x92f50a0, 
    fval=156414336, flags=2, argc=1, argv=0xbfccf66c, rval=0xbfccf65c)
    at jsinterp.c:1284
#29 0x4cdf7a55 in JS_CallFunctionValue (cx=0x910e2c8, obj=0x92f50a0, 
    fval=156414336, argc=1, argv=0xbfccf66c, rval=0xbfccf65c) at jsapi.c:4185
#30 0x02425fbb in nsJSContext::CallEventHandler (this=0x8fbf0a0, 
    aTarget=0x92f50a0, aHandler=0x952b180, argc=1, argv=0xbfccf66c, 
    rval=0xbfccf65c) at nsJSEnvironment.cpp:1456
#31 0x02460bdc in nsJSEventListener::HandleEvent (this=0x9442ea8, 
    aEvent=0x95832c8) at nsJSEventListener.cpp:186
#32 0x023549eb in nsEventListenerManager::HandleEventSubType (this=0x9442e78, 
    aListenerStruct=0x9442f08, aDOMEvent=0x95832c8, aCurrentTarget=0x9583310, 
    aSubType=1, aPhaseFlags=7) at nsEventListenerManager.cpp:1687
#33 0x02355d7f in nsEventListenerManager::HandleEvent (this=0x9442e78, 
    aPresContext=0x9353030, aEvent=0xbfccfb94, aDOMEvent=0xbfccf92c, 
    aCurrentTarget=0x9583310, aFlags=7, aEventStatus=0xbfccfbf0)
    at nsEventListenerManager.cpp:1788
#34 0x023ff324 in nsXULElement::HandleDOMEvent (this=0x9442e40, 
    aPresContext=0x9353030, aEvent=0xbfccfb94, aDOMEvent=0xbfccf92c, aFlags=7, 
    aEventStatus=0xbfccfbf0) at nsXULElement.cpp:2153
#35 0x021c7343 in PresShell::HandleDOMEventWithTarget (this=0x9312930, 
    aTargetContent=0x9442e40, aEvent=0xbfccfb94, aStatus=0xbfccfbf0)
    at nsPresShell.cpp:6521
#36 0x022e492a in nsMenuFrame::OnCreate (this=0x94b5840)
    at nsMenuFrame.cpp:1795
#37 0x022e56f0 in nsMenuFrame::OpenMenuInternal (this=0x94b5840, 
    aActivateFlag=1) at nsMenuFrame.cpp:849
#38 0x022e6b5f in nsMenuFrame::OpenMenu (this=0x94b5840, aActivateFlag=1)
    at nsMenuFrame.cpp:832
#39 0x022e648c in nsMenuFrame::ToggleMenuState (this=0x94b5840)
    at nsMenuFrame.cpp:633
#40 0x022e81b2 in nsMenuFrame::HandleEvent (this=0x94b5840, 
    aPresContext=0x9353030, aEvent=0xbfcd0228, aEventStatus=0xbfcd0080)
    at nsMenuFrame.cpp:480
#41 0x021c1dc2 in PresShell::HandleEventInternal (this=0x9312930, 
    aEvent=0xbfcd0228, aView=0x9353b08, aFlags=1, aStatus=0xbfcd0080)
    at nsPresShell.cpp:6466
#42 0x021cb503 in PresShell::HandleEvent (this=0x9312930, aView=0x9353b08, 
    aEvent=0xbfcd0228, aEventStatus=0xbfcd0080, aForceHandle=1, 
    aHandled=@0xbfcd0078) at nsPresShell.cpp:6261
#43 0x0241d40a in nsViewManager::HandleEvent (this=0x922e200, aView=0x9353b08, 
    aEvent=0xbfcd0228, aCaptured=0) at nsViewManager.cpp:2557
#44 0x024212ec in nsViewManager::DispatchEvent (this=0x922e200, 
    aEvent=0xbfcd0228, aStatus=0xbfcd0190) at nsViewManager.cpp:2246
#45 0x02418581 in HandleEvent (aEvent=0xbfcd0228) at nsView.cpp:171
#46 0x0021148c in nsCommonWidget::DispatchEvent (this=0x9312730, 
    aEvent=0xbfcd0228, aStatus=@0xbfcd0278) at nsCommonWidget.cpp:219
#47 0x0020c0ef in nsWindow::OnButtonPressEvent (this=0x9312730, 
    aWidget=0x933e938, aEvent=0x92265a0) at nsWindow.cpp:1573
#48 0x0020c1b2 in button_press_event_cb (widget=0x933e938, event=0x92265a0)
    at nsWindow.cpp:3729
#49 0x4f4bda60 in gtk_marshal_BOOLEAN__VOID ()
   from /usr/lib/libgtk-x11-2.0.so.0
#50 0x448ead9b in g_closure_invoke () from /lib/libgobject-2.0.so.0
#51 0x448fb433 in g_signal_chain_from_overridden ()
   from /lib/libgobject-2.0.so.0
#52 0x448fc71f in g_signal_emit_valist () from /lib/libgobject-2.0.so.0
#53 0x448fcb19 in g_signal_emit () from /lib/libgobject-2.0.so.0
#54 0x4f5d2508 in gtk_widget_get_default_style ()
   from /usr/lib/libgtk-x11-2.0.so.0
#55 0x4f4b6e33 in gtk_propagate_event () from /usr/lib/libgtk-x11-2.0.so.0
#56 0x4f4b8037 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0
#57 0x4f33d12a in gdk_add_client_message_filter ()
   from /usr/lib/libgdk-x11-2.0.so.0
#58 0x4486d442 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
#59 0x4487041f in g_main_context_check () from /lib/libglib-2.0.so.0
#60 0x448707c9 in g_main_loop_run () from /lib/libglib-2.0.so.0
#61 0x4f4b84b4 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#62 0x0020ffb7 in nsAppShell::Run (this=0x9109358) at nsAppShell.cpp:139
#63 0x056cde96 in nsAppStartup::Run (this=0x908fd88) at nsAppStartup.cpp:150
#64 0x0804f67d in XRE_main (argc=2, argv=0xbfcd0e54, aAppData=0x8065500)
    at nsAppRunner.cpp:2380
#65 0x0804ab90 in main (argc=0, argv=0x1d2ca) at nsBrowserApp.cpp:61
#66 0x4c21ef2c in __libc_start_main () from /lib/libc.so.6
#67 0x0804aae1 in _start ()
(gdb) 

Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 385397
bug #385397 improves this, as we have an optimized query now.  but this is for places builds (trunk).

the original bug was an issue with the mork based history.  

if someone out there has a ginormous [1] history.dat that was showing this problem in fx 2, I'd like to see what happens if they migrate to the trunk and compare a build without the fix for bug #385397 to a build with it.

if someone has a history.dat like that (that they want share privately), that would be great, too.

[1] http://www.merriam-webster.com/dictionary/ginormous
I testing fx 2 with Jay Patel's big history.dat, and I could see the slowness in fx 2.  I was able to verify that the trunk, with the fix for bug #385397, makes it much faster.  

so I feel good about this being marked as a duplicate (thanks jesse).  marking as verified.

but I would still appreciate feedback (or history.dat files) from the original bug reporter or anyone else seeing this, or confirmation.
Status: RESOLVED → VERIFIED
paraphrasing schrep (who has a monster history.dat):

history menu is instantaneous in trunk and takes about 2 secs on FF2.
You need to log in before you can comment on or make changes to this bug.