Closed Bug 184202 Opened 22 years ago Closed 21 years ago

Firebird autocomplete crash - MFB06 [@ nsTreeSelection::SetCurrentIndex] [@ nsTreeRange::Invalidate] select form field

Categories

(Core :: XUL, defect)

defect
Not set
critical

Tracking

()

VERIFIED FIXED

People

(Reporter: nate, Assigned: hewitt)

References

Details

(Keywords: crash, topcrash)

Crash Data

Attachments

(8 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021029 Phoenix/0.4
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021029 Phoenix/0.4

When using form autocomplete via mouse or keyboard, Phoenix often (multiple
times per day) crashes.  I reported this as bug #181094 for Mozilla (including a
reproducible test case and a stack trace), but it's been a week and I've gotten
no response.  But recently I've been wondering if this might be a Phoenix bug.  

Based on other people's reports, the bug is multiplatform. I've found it in the
0.4 release, and in the nightlies.  It's been a hard bug for me to debug under
Linux, since the crash seems to grab the keyboard and freeze the window manager.
 I was hoping I could solve it myself, but I'm not making much progress.

I think the problem is a runaway pointer, since there seem to be many different
but related ways of causing the crash, although it may be a threading issue. 
The problem seems to be related to forms appearing in newly created windows.

Stack trace and test case to follow.


Reproducible: Always

Steps to Reproduce:
This test case should be saved to a local drive before testing.  If you try 
to run it in place on the bugzilla server, the form submissions necessary to
reproduce the bug will confuse the bugzilla server. 

Almost all the details of this test case are arbitrary, other than the use of
autocomplete and the creation of and switching between windows.  The use of "#"
as a target is merely a convenience to get the test case down to one file.
This is a Linux stack trace from the crash caused by the autocomplete bug.  It
is consistent for the test case I gave, but the deepest functions seem to vary
with other similar cases.  Contact tom at redpepperracing for access to one.

This stack trace was difficult to capture, since the crash freezes the window
manager until Phoenix exits.  I found it necessary to start Phoenix from a
virtual terminal using "DISPLAY=:0.0 phoenix -g 1 > phoenix.out 2>&1" and run
the debugger blind using "tail -f phoenix.out" in another virtual terminal. If
you know of a better way to do this with gdb, please tell me for future use.
I can confirm what Mr. Kurz reported, that this is a reproducible bug affecting
Phoenix, since at least 0.4, and it has not been resolved in 0.5. The bug also
affects Phoenix under Windows XP. It seems to happen more frequently when
multiple windows are open.
we have several similar bugs here for one and the same problem:

bug #181094
bug #179821
bug #178395
and bug #178322

As this bug here seem to be the one containing the most valuable information
with useful test-case and back-trace I would suggest to duplicate the above
mentioned bugs and to focus on this one.

Changed state to "New" (as we obviously have enough confirmations on this) and
added keyword "Crash"...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: crash
Problems related to this bug have been reported for Linux, Windows 98, Windows
2000, Windows XP and Windows Me - hence OS-type will be set to "All", as all
means "more than one - and probably all".
OS: Linux → All
*** Bug 181094 has been marked as a duplicate of this bug. ***
*** Bug 179821 has been marked as a duplicate of this bug. ***
*** Bug 178395 has been marked as a duplicate of this bug. ***
*** Bug 178322 has been marked as a duplicate of this bug. ***
Attached patch my guess at a fix (obsolete) — — Splinter Review
nate@verse.com that's great. Can you do a few things for me?
1. verify my guess: in gdb use |up| to get to the nsTreeSelection frame (#1)
and |p mTree| it really should say that mTree is null. Also check that
aIndex>mMax (|p mMax| -- i'm betting mMax is -1).  
2. still in gdb, use |up| a few more times to get to frame #3 / #4 and then
|call DumpJSStack()|. That should give you another stack, but this time for the
offendinug JS. For now it'd be enough if you could attach that to this bug, but
if you like, you could use Venkman to set a breakpoint near the last JS frame
and figure out if there's a bad assumption in that code.
3. test this patch (the problem is that mTree is null, but this code doesn't
null check mTree so i think the correct fix is something closer to what i
wrote).

thanks.
Attached patch a version that compiles — — Splinter Review
... ok, so that other struct embedded in the file confused me.
ignore hunt for max, it just isn't there...
Attachment #109397 - Attachment is obsolete: true
.
Assignee: hewitt → timeless
Component: Autocomplete → XP Toolkit/Widgets: Trees
Product: Phoenix → Browser
Version: unspecified → Trunk
Attachment #109411 - Flags: superreview?(hewitt)
Attachment #109411 - Flags: review?(varga)
Here's the additional gdb info that you requested.  Because of the frozen
window manager, I ended up retyping this attachment.  Thus it's quite possible
it contains a typo or two.  It looks like mTree is non-null, but that _vptr.
within it is NULL.  I think this means your patch won't catch this case, but
I'm uncertain how the XP wrappers work, and how one is supposed to peek inside
them with gdb.
*** Bug 175302 has been marked as a duplicate of this bug. ***
timeless: maybe you should return NS_ERROR_INVALID_POINTER or _NOT_INITIALIZED
here... (if that is applicable here, I didn't look at the file, only at your patch)
Does anyone have ideas on what might cause the situation in comment #13?  Where
is _vptr supposed to be set?  Is there anything that might be overwriting it? 
This bug still grabs me multiple times per day.  I should note that unlike the
test case, it is often enough merely to mouse over the popup list without any
clicking.  I'm still eager to try to fix this problem, but I'm at a dead end. 

Timeless made a valiant effort, but I don't think his patch is going to be the
right solution.  Even if modified to check _vptr instead of mtree, it still
doesn't solve the issue of why it is null in the first place. This bug seems
related to multiple windows that contain (or have contained) the same form. What
issues relate to multiple windows?  Could this be a threading problem?
*** Bug 189139 has been marked as a duplicate of this bug. ***
*** Bug 189279 has been marked as a duplicate of this bug. ***
*** Bug 190270 has been marked as a duplicate of this bug. ***
*** Bug 191819 has been marked as a duplicate of this bug. ***
Comment on attachment 109411 [details] [diff] [review]
a version that compiles

this looks like a dangling pointer, not like a missing null check
Attachment #109411 - Flags: superreview?(hewitt)
Attachment #109411 - Flags: superreview-
Attachment #109411 - Flags: review?(varga)
Attachment #109411 - Flags: review-
If this is the same crash that I'm seeing, then it's caused by the tree
selection's dangling pointer to the tree box object. Unfortunately that pointer
doesn't get updated when the tree box object goes away or is recreated.
*** Bug 195387 has been marked as a duplicate of this bug. ***
*** Bug 195657 has been marked as a duplicate of this bug. ***
same here :(
Another thing: although I switched of the "save information ..." (not checked),
phoenix still saves those entries and tries to auto  complet unlee I clear it
every few minutes ...
I thought I had stopped seeing this crash in newer builds, but then I hit it in
the 3/12 bulid on Windows XP.
*** Bug 199398 has been marked as a duplicate of this bug. ***
Attached image Error message I received —
I'm running Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4a) Gecko/20030401
Phoenix/0.5

Phoenix used to just crash when I was using stable (Naples) 0.5.
Then I downloaded the April 1st nightly build I got this error message.

I was doing this when it crashed:
Clicked on bookmark that took me to http://omahaultimate.tripod.com/
Then clicked on "Tell me when this page is updated" link that took me here: 
http://omahaultimate.tripod.com/bin/email_when_updated/display_form
Then when I was typing in my email addy, the auto complete popped up and then I
got the error message and Phoenix crashed.
*** Bug 200721 has been marked as a duplicate of this bug. ***
This has got to be fixed.
Flags: blocking1.4b?
Keywords: nsbeta1
Varga, can you help?

/be
It looks like the problem a weak pointer that's not explicitly cleared when the
object it points to goes away.  This looks like the kind of thing that will work
most of the time, unless something else happens to be holding on to the object
that holds the weak pointer in addition to its normal ownership chain.

(Could it be a strong pointer?)
Attached file valgrind output for the crash —
Here's some output from "valgrind" that might offer more clues at to what is
happening here.  (http://developer.kde.org/~sewardj/).

Walking through it:

WARNING: NS_ENSURE_TRUE(row != nsnull) failed, file nsFormHistory.cpp, line 283

  This line is junk not related to the bug.  The code is written badly, and it 

  always causes this warning to appear.  Perhaps this could be changed?

WARNING: NS_ENSURE_TRUE(presShell) failed, file nsGenericHTMLElement.cpp, line
2684
   Don't know what is causing this.  Useful clue?

###!!! ASSERTION: Did you know you were calling |do_GetInterface()| on an
object that doesn't support the |nsIInterfaceRequestor| interface?:
'factoryPtr', file nsIInterfaceRequestorUtils.cpp, line 50
    New warning as a result of some recent changes for an unrelated bug. 
Assertion is raised when window is popup window containing form is closed. 
Might be showing a earlier symptom of same problem that causes the crash?  Look
at nsGlobalWindow.cpp:308 to see what causes this assertion.

==1667== Invalid memory access of size 4
==1667==    at 0x42B6C534: nsTreeSelection::SetCurrentIndex(int)
(nsTreeSelection.cpp:595)
    This is valgrind catching the error that will cause the crash.  mTree is
all messed up by this point, so out attempts to work with it fail badly.

==1667==    Address 0x45CD2CB8 is 0 bytes inside a block of size 36 free'd
==1667==    at 0x40147FD4: free (vg_clientfuncs.c:185)
==1667==    by 0x805A405: __builtin_delete (nsAppRunner.cpp:187)
==1667==    by 0x40148079: operator delete(void*) (vg_clientfuncs.c:208)
==1667==    by 0x428992CF: nsRange::~nsRange() (nsRange.cpp:447)
    This is interesting.  On this run (but not on most of the runs I tried)
valgrind is saying that the value of mTree (I think it is mTree) was previously
freed by the destruction of nsRange.  Which makes me think that if one knew
when and why this was being called, one could probably solve this bug.

On the other hand, most of the valgrind runs I've tried just say that the
address is not stack'ed, alloc'ed, or free'd.  So maybe this is just by chance?


But it seems worth pursuing to me, particularly by some more knowledgeable than
me.
Additional test case:

Go to Google
Enter text (don't submit)
Hit Alt-D
Enter text

*Kaboom*
Scott, you are describing bug 194581.
if this is phoenix only, then not a blocker or 1.4

if you can reproduce this in a trunk Mozilla Seamonkey build.
Flags: blocking1.4b? → blocking1.4b-
Has this been fixed as a side-effect of recent changes to Phoenix/Firebird?  I
have been extensively using the nightly builds and have not had a crash with the
2003-04-15 and later builds.  Can anyone still reproduce this with recent
nightly builds?
> Has this been fixed as a side-effect of recent changes to Phoenix/Firebird?

The bug is not fixed but there is a null check which traps the crash. See bug
201850 for more info.
I'm still experiencing the bug, so no, its not fixed.
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030427 Mozilla
Firebird/0.6
> I'm still experiencing the bug
Likewise here (Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4a) Gecko/20030424
Mozilla Firebird/0.6).  Process dump available on request.
per comment 22 and comment 33 this is not caused by a null pointer. therefore,
that bug is unrelated to this one.
>(Could it be a strong pointer?)

I don't think so, that would create a circular ref (box object -> view ->
selection -> box object)

We should change mTree to an nsWeakRef (or redesign the ownership model as a
long term solution)
I have to admit I'm not sure I'm doing the right thing here but Firebird just
crashed and I have an incident ID from Talkback: TB19775032W

Is this the right place to submit such information?
Check out http://forums.hardwarezone.com/search.php?s=
The search input box seems to demand focus even with this workaround. This is
the main reason why I'm still seeing crashes I think. On most other sites focus
is not given to the form history, but with this site, if you try to use
autocomplete, you can see the focus shifted from entry to entry as you mouseover
the autocomplete drop down menu, and this will inevitably cause crashes.
*** Bug 205304 has been marked as a duplicate of this bug. ***
*** Bug 205923 has been marked as a duplicate of this bug. ***
Still hasn't been fixed:

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030516 Mozilla
Firebird/0.6

This crashes the browser for me ALL THE TIME >:(
nate, can you try using valgrind with:
--error-limit=no --num-callers=20 -v
that should give useful info about the nsRange...
adt: nsbeta1-
Keywords: nsbeta1nsbeta1-
sugesting the change of the sumary to "Mozilla Firebird frequently crashes when
form autocomplete is used"
Summary: Phoenix frequently crashes when form autocomplete is used → Mozilla Firebird (Phoenix) frequently crashes when form autocomplete is used
Attached file more valgrind —
Invalid read of size 4
 nsTreeSelection::SetCurrentIndex(int)
Address 0x4BFA45BC is 0 bytes inside a block of size 36 free'd
 free (vg_clientfuncs.c:185)
 __builtin_delete (nsAppRunner.cpp:187)
 operator delete(void*) (vg_clientfuncs.c:208)
 nsTreeBoxObject::~nsTreeBoxObject() (nsTreeBoxObject.cpp:105)

and later...
Invalid read of size 4
 nsXULElement::QueryInterface(nsID const&, void**) (nsXULElement.cpp:669)
Address 0x48FADA18 is 0 bytes inside a block of size 52 free'd
 free (vg_clientfuncs.c:185)
 __builtin_delete (nsAppRunner.cpp:187)
 operator delete(void*) (vg_clientfuncs.c:208) 
 nsXULElement::~nsXULElement() (nsXULElement.cpp:495)

longer stacks included in attachment
here's another talkback Incident ID: TB20406433G, 
this time my email address was supposed to autocomplete
Hi!
Can anyone here still reproduce this bug using a clean profile with current
nightly builds?

I cannot reproduce this now.
I've not been able to reproduce this bug since I began using a build I created
on May 26th. So far the build I created on May 28th hasn't crashed either. I've
been using autocomplete pretty extensively, and its not crashed yet. When I used
0.6, it used to crash somewhat frequently.

I've not been using official nightlies, but I've been building directly from CVS
without adding any patches.
unable to reproduce with official nightly (may 23)
but even though I have been able to trigger the test-case, that has been my only
encounter with the autocomplete-bug.
Still happen for me: TB20543075M with 20030526 on WinXP.
It also happens to me all the time with build 20030526 on win2k and winxp. Also
maybe pure coincidence, I have never had it crash in Linux and in windows I
cannot intentionally make it crash. 

I realize that this really isn't appropriate to place here but this is a major
bug that we've all been waiting months and months to be fixed. I don't know of
any other bug that deserves more attention than this guys. I cannot recommend
firebird to general users solely because of this bug. It is incredibly
frustrating that this bug is being ignored (or so it appears).

I've sent in probably 30 talkback reports with these crashes, is there anything
else that can be done to help short of doing the actuall programming?
Bug persists in FB 2003052708 on Win2K: Crashes on Bidpay at the login prompt
when  recalling userid.
A workaround seems to be about:config | browser.formfill.enable | false.

If you're not seeing this bug, maybe you've got that preference set.

This bug applies to *form* autocomplete, not URL bar autocomplete.
Still crashing on 2003052708 WinXP.
Does Mozilla suite have this bug? If not, what's the difference?
I'd like to kill auto-complete in preference, though i'm
not using release version, but testing...
If we see no improvement in another month, then replacing
entire auto-complete component in Firebird will be better. It won't
take 1 month.
"A workaround seems to be about:config | browser.formfill.enable | false.
If you're not seeing this bug, maybe you've got that preference set."

Unfortunatelly that doesn't work, formfill is still used, that preference is
ignored and crashes occur as well as formfilling anyway.
>Does Mozilla suite have this bug? If not, what's the difference?

It doesn't. Form autocomplete was re-written in phoenix.
*** Bug 207504 has been marked as a duplicate of this bug. ***
I haven't been able to reproduce this bug since 20030521, however I know people
who still can. Very weird.
Just reproduced with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b)
Gecko/20030529 Mozilla Firebird/0.6
*** Bug 207975 has been marked as a duplicate of this bug. ***
In my experience you can ignore the autocomplete function or use the mouse. This
makes the browser act fine/normal. This makes the autocomplete almost unusable,
though.

Using the mouse to click the autocomplete defeats the purpose of the feature,
imo. I like this feature because it is supposed to save me time in filling out
web forms. Having to switch from kb to mouse is not a savings by any stretch.
This is nearly the sole reason that I have been resistant to Mozilla up until
this point. Other than this glitch, Firebird beats IE6 hands down, and IE6 imo
is it's only real competition.

Please fix this bug so that I can start evangelizing in earnest.
>In my experience you can ignore the autocomplete function or use the mouse. This
>makes the browser act fine/normal.

My Mozilla Firebird still manages to crash if i use the mouse to select one of
the auto-complete options so this does not make the browser "act" normal.
It appears that if you copy autocomplete.xpt from mozilla and use it in firebird
that its a valid work around. I haven't yet experianced a crash and it of course
doesn't have any side effects that i've seen. So those of you watching this
thread... try autocomplete.xpt from mozilla (in components dir). I copied it
from mozilla-win32-1.3.1-talkback.
making this summary a bit more queryable and adding stacktrace (this is the #1
crasher in 0.6 talkback)

  Stack Trace: 
   nsTreeSelection::SetCurrentIndex
[d:/nightlybuild/phoenix/trunk/mozilla/layout/xul/base/src/tree/src/nsTreeSelection.cpp
 line 597]
   nsTreeSelection::Select
[d:/nightlybuild/phoenix/trunk/mozilla/layout/xul/base/src/tree/src/nsTreeSelection.cpp
 line 356]
   XPTC_InvokeByIndex
[d:/nightlybuild/phoenix/trunk/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp
 line 102]
   XPCWrappedNative::CallMethod
[d:/nightlybuild/phoenix/trunk/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp
 line 2025]
   XPC_WN_CallMethod
[d:/nightlybuild/phoenix/trunk/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp
 line 1285]
   js_Invoke	[d:/nightlybuild/phoenix/trunk/mozilla/js/src/jsinterp.c  line 845]
   js_Interpret	[d:/nightlybuild/phoenix/trunk/mozilla/js/src/jsinterp.c  line 2854]
   js_Invoke	[d:/nightlybuild/phoenix/trunk/mozilla/js/src/jsinterp.c  line 861]
   js_InternalInvoke	[d:/nightlybuild/phoenix/trunk/mozilla/js/src/jsinterp.c 
line 936]
   js_InternalGetOrSet	[d:/nightlybuild/phoenix/trunk/mozilla/js/src/jsinterp.c
 line 979]
   js_SetProperty	[d:/nightlybuild/phoenix/trunk/mozilla/js/src/jsobj.c  line 2639]
   js_Interpret	[d:/nightlybuild/phoenix/trunk/mozilla/js/src/jsinterp.c  line 2694]
   js_Invoke	[d:/nightlybuild/phoenix/trunk/mozilla/js/src/jsinterp.c  line 861]
   nsXPCWrappedJSClass::CallMethod
[d:/nightlybuild/phoenix/trunk/mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp
 line 1334]
   nsXPCWrappedJS::CallMethod
[d:/nightlybuild/phoenix/trunk/mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp 
line 429]
   PrepareAndDispatch
[d:/nightlybuild/phoenix/trunk/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp
 line 119]
   SharedStub
[d:/nightlybuild/phoenix/trunk/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp
 line 147]
   nsAutoCompleteController::HandleKeyNavigation
[d:/nightlybuild/phoenix/trunk/mozilla/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp
 line 292]
   nsFormFillController::KeyPress
[d:/nightlybuild/phoenix/trunk/mozilla/toolkit/components/satchel/src/nsFormFillController.cpp
 line 547]
   nsEventListenerManager::HandleEvent
[d:/nightlybuild/phoenix/trunk/mozilla/content/events/src/nsEventListenerManager.cpp
 line 1637]
   nsGenericElement::HandleDOMEvent
[d:/nightlybuild/phoenix/trunk/mozilla/content/base/src/nsGenericElement.cpp 
line 1925]
   nsHTMLInputElement::HandleDOMEvent
[d:/nightlybuild/phoenix/trunk/mozilla/content/html/content/src/nsHTMLInputElement.cpp
 line 1445]
   PresShell::HandleEventInternal
[d:/nightlybuild/phoenix/trunk/mozilla/layout/html/base/src/nsPresShell.cpp 
line 6397]
   PresShell::HandleEvent
[d:/nightlybuild/phoenix/trunk/mozilla/layout/html/base/src/nsPresShell.cpp 
line 6320]
   nsViewManager::HandleEvent
[d:/nightlybuild/phoenix/trunk/mozilla/view/src/nsViewManager.cpp  line 2268]
   nsView::HandleEvent
[d:/nightlybuild/phoenix/trunk/mozilla/view/src/nsView.cpp  line 308]
   nsViewManager::DispatchEvent
[d:/nightlybuild/phoenix/trunk/mozilla/view/src/nsViewManager.cpp  line 2050]
   HandleEvent	[d:/nightlybuild/phoenix/trunk/mozilla/view/src/nsView.cpp  line 82]
   nsWindow::DispatchEvent
[d:/nightlybuild/phoenix/trunk/mozilla/widget/src/windows/nsWindow.cpp  line 1058]
   nsWindow::DispatchWindowEvent
[d:/nightlybuild/phoenix/trunk/mozilla/widget/src/windows/nsWindow.cpp  line 1075]
   nsWindow::DispatchKeyEvent
[d:/nightlybuild/phoenix/trunk/mozilla/widget/src/windows/nsWindow.cpp  line 2932]
   nsWindow::OnKeyDown
[d:/nightlybuild/phoenix/trunk/mozilla/widget/src/windows/nsWindow.cpp  line 3021]
   USER32.dll + 0x5793 (0x77d45793)

    Source File: 
d:/nightlybuild/phoenix/trunk/mozilla/layout/xul/base/src/tree/src/nsTreeSelection.cpp
line : 597
Summary: Mozilla Firebird (Phoenix) frequently crashes when form autocomplete is used → firebird autocomplete crash nsTreeSelection::SetCurrentIndex select form field
Re comment #70:
Gave this workaround a try but replacing Moz.Firebird 2003-06-03
autocomplete.xpt by the 2003-06-03 autocomplete.xpt from SeaMonkey causes
Moz.Firebird to crash in XPCOM.DLL just right after selecting a profile. 
So at least on my box (WinNT4.0) this workaround seems to fail :(
.
Assignee: timeless → hewitt
Summary: firebird autocomplete crash nsTreeSelection::SetCurrentIndex select form field → firebird autocomplete crash [@ nsTreeSelection::SetCurrentIndex] select form field
um, just downloaded and installed the latest nightly build...IT'S WORKING!!!

I tried all the same stuff that usually makes my junk crash, and it's working,
just like IE does. arrow down to the result you want, press enter to select it,
and enter to submit the form.

I'm so happy I could cry.
Mellissa
*** Bug 209257 has been marked as a duplicate of this bug. ***
I can still reproduce crashes - talkback IDs TB21031309M and TB21021441X. Also
just reproduced with test case: TB21031609X.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030611 Mozilla
Firebird/0.6

Re: comment 68: you cannot ignore the form autocomplete - it triggers
automatically when typing into the text field - you cannot avoid it popping up,
which is when it crashes.

Re: comment 74: have you tried the test case again? Have you opened and closed
windows?
Francis,

I did try the test case. I followed the instructions correctly, and that all
works fine, the only part that does not is after all that I typed fo into the
form, and the foo1 and foo2 dropped down as choices. If I use the mouse to try
to click on them, firebird crashes. But still, this is more than half the
battle!!! For me this is great, because I rarely, if ever, use the mouse to
click on these.

Mellissa

I still get the crashes also... The bug is not fixed
Adding topcrash keyword since this is the #1 crash for Mozilla FireBird .06. 
Also see bug 189005.  That might be a dup.
Keywords: topcrash
Summary: firebird autocomplete crash [@ nsTreeSelection::SetCurrentIndex] select form field → firebird autocomplete crash - MFB06 [@ nsTreeSelection::SetCurrentIndex] select form field
Adding nsTreeRange::Invalidate to summary since that stack signature is also
being reported by Mozilla Firebird .06 users trying to use autocomplete.  Here
is the latest from Talkback for those crashes:

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Rank    StackSignature    Count  

11   nsTreeRange::Invalidate   66 

 
 	Source File :
d:/nightlybuild/phoenix/trunk/mozilla/layout/xul/base/src/tree/src/nsTreeSelection.cpp
line : 216
 
====================================================================================================
     Count   Offset    Real Signature
[ 5   nsTreeRange::Invalidate a2172430 - nsTreeRange::Invalidate ]
[ 3   nsTreeRange::Invalidate 823caccd - nsTreeRange::Invalidate ]
[ 3   nsTreeRange::Invalidate 13e4a738 - nsTreeRange::Invalidate ]
[ 2   nsTreeRange::Invalidate 8af81454 - nsTreeRange::Invalidate ]
[ 2   nsTreeRange::Invalidate 5e95cd7d - nsTreeRange::Invalidate ]
 
     Crash date range: 2003-06-06 to 2003-06-13
     Min/Max Seconds since last crash: 2904 - 1396050
     Min/Max Runtime: 19834 - 2227763
 
     Count   Platform List 
     8   Windows NT 5.1 build 2600
     5   Windows NT 5.0 build 2195
     2   Windows NT 4.0 build 1381
 
     Count   Build Id List 
     15   2003051616
 
     No of Unique Users        15
 
 Stack trace(Frame) 

	 nsTreeRange::Invalidate
[d:/nightlybuild/phoenix/trunk/mozilla/layout/xul/base/src/tree/src/nsTreeSelection.cpp
 line 216] 
	 nsTreeSelection::Select
[d:/nightlybuild/phoenix/trunk/mozilla/layout/xul/base/src/tree/src/nsTreeSelection.cpp
 line 371] 
	 XPTC_InvokeByIndex
[d:/nightlybuild/phoenix/trunk/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp
 line 102] 
	 XPCWrappedNative::CallMethod
[d:/nightlybuild/phoenix/trunk/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp
 line 2025] 
	 XPC_WN_CallMethod
[d:/nightlybuild/phoenix/trunk/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp
 line 1285] 
	 js_Invoke	[d:/nightlybuild/phoenix/trunk/mozilla/js/src/jsinterp.c  line 845] 
	 js_Interpret	[d:/nightlybuild/phoenix/trunk/mozilla/js/src/jsinterp.c  line 2854] 
	 js_Invoke	[d:/nightlybuild/phoenix/trunk/mozilla/js/src/jsinterp.c  line 861] 
	 js_InternalInvoke	[d:/nightlybuild/phoenix/trunk/mozilla/js/src/jsinterp.c 
line 936] 
	 js_InternalGetOrSet	[d:/nightlybuild/phoenix/trunk/mozilla/js/src/jsinterp.c 
line 979] 
	 js_SetProperty	[d:/nightlybuild/phoenix/trunk/mozilla/js/src/jsobj.c  line 2639] 
	 JS_SetProperty	[d:/nightlybuild/phoenix/trunk/mozilla/js/src/jsapi.c  line 2456] 
	 nsXPCWrappedJSClass::CallMethod
[d:/nightlybuild/phoenix/trunk/mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp
 line 1314] 
	 nsXPCWrappedJS::CallMethod
[d:/nightlybuild/phoenix/trunk/mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp 
line 429] 
	 PrepareAndDispatch
[d:/nightlybuild/phoenix/trunk/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp
 line 119] 
	 SharedStub
[d:/nightlybuild/phoenix/trunk/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp
 line 147] 
	 nsAutoCompleteController::ClosePopup
[d:/nightlybuild/phoenix/trunk/mozilla/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp
 line 653] 
	 nsAutoCompleteController::ProcessResult
[d:/nightlybuild/phoenix/trunk/mozilla/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp
 line 868] 
	 nsAutoCompleteController::OnSearchResult
[d:/nightlybuild/phoenix/trunk/mozilla/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp
 line 382] 
	 nsFormFillController::StartSearch
[d:/nightlybuild/phoenix/trunk/mozilla/toolkit/components/satchel/src/nsFormFillController.cpp
 line 429] 
	 nsAutoCompleteController::StartSearch
[d:/nightlybuild/phoenix/trunk/mozilla/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp
 line 688] 
	 nsAutoCompleteController::Notify
[d:/nightlybuild/phoenix/trunk/mozilla/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp
 line 395] 
	 nsTimerImpl::Fire
[d:/nightlybuild/phoenix/trunk/mozilla/xpcom/threads/nsTimerImpl.cpp  line 395] 
	 nsAppShell::Run
[d:/nightlybuild/phoenix/trunk/mozilla/widget/src/windows/nsAppShell.cpp  line 143] 
	 nsAppShellService::Run
[d:/nightlybuild/phoenix/trunk/mozilla/xpfe/appshell/src/nsAppShellService.cpp 
line 479] 
	 main1	[d:/nightlybuild/phoenix/trunk/mozilla/toolkit/xre/nsAppRunner.cpp  line
1297] 
	 xre_main	[d:/nightlybuild/phoenix/trunk/mozilla/toolkit/xre/nsAppRunner.cpp 
line 1698] 
	 main	[d:/nightlybuild/phoenix/trunk/mozilla/browser/app/nsBrowserApp.cpp  line
52] 
	 WinMain	[d:/nightlybuild/phoenix/trunk/mozilla/browser/app/nsBrowserApp.cpp 
line 65] 
	 WinMainCRTStartup()  
	 kernel32.dll + 0x214c7 (0x77e814c7)   
 
     (21016980)	URL: www.imdb.com
     (21016980)	Comments: Filling in search form
     (21006586)	Comments: typing in text box  drop-down list of history appears
 then crashes
     (20996103)	Comments: autocomplete
     (20974781)	Comments: filling out php form
     (20950011)	URL: usercenter.checkpoint.com
     (20950011)	Comments: Authenticating to an ssl site
     (20824904)	URL: http://www.gutrumbles.com
     (20824904)	Comments: once again I was posting on a weblog and duh!!
     (20821611)	URL: maps.yahoo.com
     (20821611)	Comments: autocomplete (again)
     (20819446)	URL: http://www.google.co.uk/imghp
     (20819446)	Comments: Started typing in to the search box and it crashed
     (20816092)	Comments: opened new tab... i had windows update service pack 1
in backround that just switched from unzipping to downloading patches and updates
 
====================================================================================================
     Count   Offset    Real Signature
[ 5   nsTreeRange::Invalidate 644566b0 - nsTreeRange::Invalidate ]
[ 3   nsTreeRange::Invalidate d5b6e5b8 - nsTreeRange::Invalidate ]
[ 2   nsTreeRange::Invalidate 446eee4d - nsTreeRange::Invalidate ]
 
     Crash date range: 2003-06-06 to 2003-06-14
     Min/Max Seconds since last crash: 63 - 1544878
     Min/Max Runtime: 28790 - 1544878
 
     Count   Platform List 
     7   Windows NT 5.1 build 2600
     3   Windows NT 5.0 build 2195
 
     Count   Build Id List 
     10   2003051616
 
     No of Unique Users        10
 
 Stack trace(Frame) 

	 nsTreeRange::Invalidate
[d:/nightlybuild/phoenix/trunk/mozilla/layout/xul/base/src/tree/src/nsTreeSelection.cpp
 line 216] 
	 0xffffffff  
	 XPCWrappedNative::CallMethod
[d:/nightlybuild/phoenix/trunk/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp
 line 2025] 
	 XPC_WN_CallMethod
[d:/nightlybuild/phoenix/trunk/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp
 line 1285] 
	 js_Invoke	[d:/nightlybuild/phoenix/trunk/mozilla/js/src/jsinterp.c  line 845] 
	 js_Interpret	[d:/nightlybuild/phoenix/trunk/mozilla/js/src/jsinterp.c  line 2854] 
	 js_Invoke	[d:/nightlybuild/phoenix/trunk/mozilla/js/src/jsinterp.c  line 861] 
	 js_InternalInvoke	[d:/nightlybuild/phoenix/trunk/mozilla/js/src/jsinterp.c 
line 936] 
	 js_InternalGetOrSet	[d:/nightlybuild/phoenix/trunk/mozilla/js/src/jsinterp.c 
line 979] 
	 js_SetProperty	[d:/nightlybuild/phoenix/trunk/mozilla/js/src/jsobj.c  line 2639] 
	 JS_SetProperty	[d:/nightlybuild/phoenix/trunk/mozilla/js/src/jsapi.c  line 2456] 
	 nsXPCWrappedJSClass::CallMethod
[d:/nightlybuild/phoenix/trunk/mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp
 line 1314] 
	 nsXPCWrappedJS::CallMethod
[d:/nightlybuild/phoenix/trunk/mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp 
line 429] 
	 PrepareAndDispatch
[d:/nightlybuild/phoenix/trunk/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp
 line 119] 
	 SharedStub
[d:/nightlybuild/phoenix/trunk/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp
 line 147] 
	 nsAutoCompleteController::ClosePopup
[d:/nightlybuild/phoenix/trunk/mozilla/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp
 line 653] 
	 nsAutoCompleteController::ProcessResult
[d:/nightlybuild/phoenix/trunk/mozilla/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp
 line 868] 
	 nsAutoCompleteController::OnSearchResult
[d:/nightlybuild/phoenix/trunk/mozilla/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp
 line 382] 
	 nsFormFillController::StartSearch
[d:/nightlybuild/phoenix/trunk/mozilla/toolkit/components/satchel/src/nsFormFillController.cpp
 line 429] 
	 nsAutoCompleteController::StartSearch
[d:/nightlybuild/phoenix/trunk/mozilla/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp
 line 688] 
	 nsAutoCompleteController::Notify
[d:/nightlybuild/phoenix/trunk/mozilla/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp
 line 395] 
	 nsTimerImpl::Fire
[d:/nightlybuild/phoenix/trunk/mozilla/xpcom/threads/nsTimerImpl.cpp  line 395] 
	 nsAppShell::Run
[d:/nightlybuild/phoenix/trunk/mozilla/widget/src/windows/nsAppShell.cpp  line 143] 
	 nsAppShellService::Run
[d:/nightlybuild/phoenix/trunk/mozilla/xpfe/appshell/src/nsAppShellService.cpp 
line 479] 
	 main1	[d:/nightlybuild/phoenix/trunk/mozilla/toolkit/xre/nsAppRunner.cpp  line
1297] 
	 xre_main	[d:/nightlybuild/phoenix/trunk/mozilla/toolkit/xre/nsAppRunner.cpp 
line 1698] 
	 main	[d:/nightlybuild/phoenix/trunk/mozilla/browser/app/nsBrowserApp.cpp  line
52] 
	 WinMain	[d:/nightlybuild/phoenix/trunk/mozilla/browser/app/nsBrowserApp.cpp 
line 65] 
	 WinMainCRTStartup()  
	 kernel32.dll + 0x214c7 (0x77e814c7)   
 
     (21042799)	URL: http://www.google.com
     (21040563)	URL: www.amazon.com
     (21040563)	Comments: I had three windows open  I was on Autotrader.com and
entering my zip when it froze then crashed.
     (21030930)	Comments: Filling in a form.  First time ever I got the dreaded
form autocomplete.  :-(  I would actually like to turn it OFF  but there's that
other bug...
     (20910964)	URL: www.google.com
     (20910964)	Comments: Googled. Did a Back  entered new search criteria 
pressed Enter  boom crash...
 
Summary: firebird autocomplete crash - MFB06 [@ nsTreeSelection::SetCurrentIndex] select form field → Firebird autocomplete crash - MFB06 [@ nsTreeSelection::SetCurrentIndex] [@ nsTreeRange::Invalidate] select form field
*** Bug 209950 has been marked as a duplicate of this bug. ***
Came to bugzilla to report an autocomplete crash in Phoenix 0.5 and Firebird 0.6
(exists in both), and I'm almost certain it's a dupe of this.  Joy.

So instead, I'll vote for this bug and contribute another surefire test case. 
This repros on Firebird/0.6 on MacOS X and Win32.  (oooh, cross platform!)

go to http://www.haagen-dazs.com
click "Promotions and Events"
Pick one of the two contests on the left, enter your personal information and
submit the entry.  Agree to save form data.
Pick the other contest, fill out the data.  It's sort of unpredictable -
sometimes, you have to double-click the autocomplete data in the dropdown list
to break Firebird, and other times it breaks when just typing the data in
without clicking anything.  Either way, if it doesn't blow up in the second
attempted contest entry, close that popup window and open up a third and it will.

This isn't anything new...  reading through past comments, it sounds like some
work had been done tracing it to popup windows, and that is definitely the case
here (they placed the entry blank as a popup).  I expect the test case already
in the bug is the same exact problem.

I filed a talkback incident, id TB21258314E, from a Win2k box just in case that
helps.
Alias: autocomplete
Neil has a possible fix for this.
I can't reproduce this bug on linux, but from my point of view Neil's patch
looks promising.
Attached patch Patch based on bug 190447 — — Splinter Review
This will stop pointers from dangling.
Any remaining crash would then be caused by a null pointer.
Attachment #126461 - Flags: review+
can't wait for a (new) beos-nightly, since I also ran into this:
(enclosing my stack-crawl in case it's useful)

loading symbols
segment violation occurred
00650068 read_fault
MozillaFirebird-bin:sc
   frame         retaddr
fcfffecc   ed27d5d1  nsTreeSelection::Select(int) + 00000035
fcfffee8   ec9e7f5f  XPTC_InvokeByIndex + 00000057
fcffff0c   ecba1b5d  XPCWrappedNative::CallMethod(XPCCallContext &,
XPCWrappedNative::CallMode) + 00000c95
fd000118   ecba6f42  XPC_WN_CallMethod(JSContext *, JSObject *, unsigned int,
long *, long *) + 000000a2
fd0001c4   ec90a143  js_Invoke + 0000058f
fd000290   ec9115c2  js_Interpret + 00006916
fd000458   ec90a193  js_Invoke + 000005df
fd000518   ec90a397  js_InternalInvoke + 000000a7
fd0005a4   ec90a4be  js_InternalGetOrSet + 000000e6
fd0005d4   ec91bb36  js_SetProperty + 0000028a
fd000650   ec910b77  js_Interpret + 00005ecb
fd00081c   ec90a193  js_Invoke + 000005df
fd0008dc   ecb9df73  nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS *, unsigned
short, nsXPTMethodInfo const *, nsXPTCMiniVariant *) + 00000c03
fd000b00   ecb99dd2  nsXPCWrappedJS::CallMethod(unsigned short, nsXPTMethodInfo
const *, nsXPTCMiniVariant *) + 0000003e
fd000b28   ec9e80ef  PrepareAndDispatch(nsXPTCStubBase *, unsigned long,
unsigned int *) + 0000017f
fd000be8   ec9e82bc  nsXPTCStubBase::Stub11(void) + 00000024
fd000c00   eddf3d14  nsAutoCompleteController::HandleKeyNavigation(unsigned
short, int *) + 00000130
fd000ccc   ede04a1a  nsFormFillController::KeyPress(nsIDOMEvent *) + 000001ea
fd000d08   ed11ec74  nsEventListenerManager::HandleEvent(nsIPresContext *,
nsEvent *, nsIDOMEvent **, nsIDOMEventTarget *, unsigned int, nsEventStatus *) +
00001618
fd000e98   ed0c7262  nsGenericElement::HandleDOMEvent(nsIPresContext *, nsEvent
*, nsIDOMEvent **, unsigned int, nsEventStatus *) + 000008b2
fd000fe0   ed163403  nsHTMLInputElement::HandleDOMEvent(nsIPresContext *,
nsEvent *, nsIDOMEvent **, unsigned int, nsEventStatus *) + 0000079f
fd001240   ecfa54f2  PresShell::HandleEventInternal(nsEvent *, nsIView *,
unsigned int, nsEventStatus *) + 000002b6
fd0012a8   ecfa516f  PresShell::HandleEvent(nsIView *, nsGUIEvent *,
nsEventStatus *, int, int &) + 000005a7
fd001320   ed2662f0  nsViewManager::HandleEvent(nsView *, nsGUIEvent *, int) +
000000dc
fd001400   ed25e5ba  nsView::HandleEvent(nsViewManager *, nsGUIEvent *, int) +
00000026
fd001420   ed265ac3  nsViewManager::DispatchEvent(nsGUIEvent *, nsEventStatus *)
+ 00000827
fd00149c   ed25e034  HandleEvent(nsGUIEvent *) + 00000044
fd0014bc   ed75746d  nsWindow::DispatchEvent(nsGUIEvent *, nsEventStatus &) +
00000049
fd0014d8   ed7574e2  nsWindow::DispatchWindowEvent(nsGUIEvent *) + 00000036
fd0014f8   ed75af58  nsWindow::DispatchKeyEvent(unsigned int, unsigned int,
unsigned int) + 000000bc
fd001578   ed75adfd  nsWindow::OnKeyDown(unsigned int, char const *, long,
unsigned int, unsigned int, long) + 00000205
fd0015a0   ed75a84f  nsWindow::CallMethod(MethodInfo *) + 0000045f
fd001640   ed752526  nsAppShell::Run(void) + 000000ba
fd001668   ed717a88  nsAppShellService::Run(void) + 00000024
fd001678   8000ef62  main1(int, char **, nsISupports *, nsXREAppData const &) +
000008be
fd001784   8000f541  xre_main(int, char **, nsXREAppData const &) + 000002a5
fd0017e4   8000b4f6  main + 00000092
fd001824   8000b355  _start + 00000061
MozillaFirebird-bin:regs
 eax 00650068   ebp fcfffecc   cs 001b
 edx 0000002f   esi 80fc6030   ss 0023
 ecx 804575e0   edi 00000000   ds 0023
 ebx ed58a0bc   esp fcfffeb4   es 0023
                               fs 340b
 eflags 00010286  eip 00650068
 trap_no 0000000e  error_code 00000005
MozillaFirebird-bin:ps
 PID  DEBUG NAME                              STATUS
 672  curr  MozillaFirebird-bin               semaphore
 675        BApplication                      semaphore
 67a        moz-thread                        semaphore
 67b        moz-thread                        semaphore
 67e        moz-thread                        semaphore
 d14        moz-thread                        semaphore
 ddc        w>PegasosPPC.com - - Mozilla Fi   semaphore
 de9        w>                                semaphore
 dea        w>                                semaphore
 e33        w>                                semaphore
 e34        w>                                semaphore
 e35        team 243 debugtask                semaphore
MozillaFirebird-bin:

brg,
Hugh
Still present as of nightly build 06/26 on Windows XP Pro. Fresh install, fresh profile, first thing I tried. I can reproduce it 100% so if anyone needs to see it happen...

It didn't appear to happen with the first time I tried it, so I tried it again, and sure enough, crash.
Comment on attachment 126461 [details] [diff] [review]
Patch based on bug 190447

jag, could you sr?
Attachment #126461 - Flags: superreview?(jaggernaut)
Comment on attachment 126461 [details] [diff] [review]
Patch based on bug 190447

Just to make sure, in the |!sel| case where you create a new TreeSelection,
shouldn't you also do sel->SetTree()?
jag: NS_NewTreeSelection(mTreeBoxObject, getter_AddRefs(sel)); effectively calls
sel->SetTree(mTreeBoxObject); in the nsTreeSelection constructor.
Comment on attachment 126461 [details] [diff] [review]
Patch based on bug 190447

sr=jag
Attachment #126461 - Flags: superreview?(jaggernaut) → superreview+
Just checked the fix in, so let's see if this makes any difference.
I tried to test it with the 20030709 build, but it looks like auto-completion
has been disabled ? ("browser.formfill.enable" is set to "true")
disabled or broken - bug 212220. Seems to have stopped working before this was
checked in, so probably not related. But obviously it's not possible to test
this until autocomplete actually works...
There are still some wired behaviors about autocomplete.
But, so far I can see no autocomplete crash anymore!
noririty, what build are you using?
*** Bug 212588 has been marked as a duplicate of this bug. ***
*** Bug 212657 has been marked as a duplicate of this bug. ***
Using an unoffical 07/14 build, on Windows XP, I get the following behaviour: using the keyboard only, if there are >1 items on the autocomplete list you can only select the first item. As soon as you press the down arrow button, it automatically selects the first item and returns you to the field. Using the mouse you can select any of the items....ah....after some more testing, it appears to try and auto-limit the entries such that as you select entries it narrows the list. Still some oddities there, but at least no crashes!
I tried cvs HEAD.
Marking as FIXED as I can still confirm fixed with 2003-07-14-15-trunk.

Selecting with keyboard issue should be filed with another bug.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Finally its fixed, I'm one happy guy :)

Anyway, the selecting with keyboard issue has been filed by myself yesterday as
Bug 212686
*** Bug 212890 has been marked as a duplicate of this bug. ***
verified fixed.
Status: RESOLVED → VERIFIED
*** Bug 212952 has been marked as a duplicate of this bug. ***
*** Bug 212969 has been marked as a duplicate of this bug. ***
*** Bug 215337 has been marked as a duplicate of this bug. ***
*** Bug 215363 has been marked as a duplicate of this bug. ***
Found out that bug 216483 was a dupe of this bug. I already marked (my own) bug
report as invalid. Yes, another case of this in Firebird 0.6.
*** Bug 190447 has been marked as a duplicate of this bug. ***
*** Bug 217704 has been marked as a duplicate of this bug. ***
*** Bug 223593 has been marked as a duplicate of this bug. ***
I am able to produce an apparently autocomplete related crash in Firefox 0.9.1
on Linux/amd64 (Gentoo ~amd64, last emerge -u world 2004/July/21).

I was able to reproduce consistantly with the following steps:
1.) Start firefox.
2.) Go to http://www.google.com/
    (It seems to be able to crash on any form a text control and 
      remembered stuff to autocomplete)
3.) Type in something that will cause autocomplete to pop up with choices,
    my tests had 2 or three different choices, but one choice may crash too.
4.) It might crash. If it doesn't, delete the text in the box and type it
    again. Typing speed *may* be linked - it seems like it crashes more
    if I'm typing quickly, but that's probably just that it has more chances
    to crash.
5.) In order to reproduce, I need to repeat step 3 an average of 3 times.
    This comes up (frequently) in normal browsing, so it's not nessisary to
    repeat it on a given form element to work, but it may not trigger on the
    first form element filled during the browser session - on the other hand,
    it may.

I'd have opened a new bug, but it looks like every bug that was even vaguely
similar to this got DUPED to this bug.
Nat: Did a Talkback Quality Feedback Agent popup when you crashed?  If you
submitted an incident, please post the id here.  You can find it by running
talkback in the mozilla components/talkback directory.  If you didn't see a
crash dialog after the crash, install a recent release or nightly with Talkback
and try crashing again.  Thanks.
Jay: I can't find an easy way to get a talkback build running on my platform
(mostly-pure 64bit amd64 Linux). I don't have a 32bit Linux system to try that
on, but I may be able to fake it later. I cannot duplicate the crash on WinXP.
nat@ferrus.net: please file a new bug.
Component: XP Toolkit/Widgets: Trees → XUL
QA Contact: asa → xptoolkit.widgets
Alias: autocomplete
Crash Signature: [@ nsTreeSelection::SetCurrentIndex] [@ nsTreeRange::Invalidate]
You need to log in before you can comment on or make changes to this bug.