Closed Bug 44093 Opened 24 years ago Closed 24 years ago

crash scrolling folder pane [@ nsXULTreeOuterGroupFrame::FindPreviousRowContent]

Categories

(Core :: XUL, defect, P1)

x86
Windows NT
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: Bienvenu, Assigned: hyatt)

References

Details

(Keywords: crash, topcrash, Whiteboard: [nsbeta3-][PDTP1][rtm++])

Crash Data

Attachments

(2 files)

parentContent is null, here's the stack trace.  What happens is that I'll read a 
few messages, scroll the folder pane around a bit, and then get in a situation 
where the folder pane stops painting, so that it ends up blank. Right after 
that, I crash. Nothing interesting is displayed on the console.

nsXULTreeOuterGroupFrame::FindPreviousRowContent(int & 0x00000001, nsIContent * 
0x00000000, nsIContent * 0x00000000, nsIContent * * 0x0012f38c) line 813 + 47 
bytes
nsXULTreeOuterGroupFrame::InternalPositionChanged(nsXULTreeOuterGroupFrame * 
const 0x02838970, int 0x00000001, int 0x00000001) line 494 + 47 bytes
nsXULTreeOuterGroupFrame::PositionChanged(nsXULTreeOuterGroupFrame * const 
0x02838a24, int 0x000002c1, int 0x000002b2) line 452
nsSliderFrame::SetCurrentPosition(nsIContent * 0x033d2180, nsIFrame * 
0x028393b8, int 0x000002b2) line 692
nsSliderFrame::HandleEvent(nsSliderFrame * const 0x028392f8, nsIPresContext * 
0x02527b70, nsGUIEvent * 0x0012f8a8, nsEventStatus * 0x0012f798) line 454
PresShell::HandleEventInternal(nsEvent * 0x0012f8a8, nsIView * 0x033d96d0, 
nsEventStatus * 0x0012f798) line 3917 + 38 bytes
PresShell::HandleEvent(PresShell * const 0x02679b54, nsIView * 0x033d96d0, 
nsGUIEvent * 0x0012f8a8, nsEventStatus * 0x0012f798, int & 0x00000001) line 3837 
+ 23 bytes
nsView::HandleEvent(nsView * const 0x033d96d0, nsGUIEvent * 0x0012f8a8, unsigned 
int 0x0000001c, nsEventStatus * 0x0012f798, int & 0x00000001) line 782
nsViewManager2::DispatchEvent(nsViewManager2 * const 0x026783c0, nsGUIEvent * 
0x0012f8a8, nsEventStatus * 0x0012f798) line 1389
HandleEvent(nsGUIEvent * 0x0012f8a8) line 69
nsWindow::DispatchEvent(nsWindow * const 0x026780b4, nsGUIEvent * 0x0012f8a8, 
nsEventStatus & nsEventStatus_eIgnore) line 560 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f8a8) line 581
nsWindow::DispatchMouseEvent(unsigned int 0x0000012c, nsPoint * 0x00000000) line 
3679 + 21 bytes
ChildWindow::DispatchMouseEvent(unsigned int 0x0000012c, nsPoint * 0x00000000) 
line 3886
nsWindow::ProcessMessage(unsigned int 0x00000200, unsigned int 0x00000001, long 
0x01c900bf, long * 0x0012fc24) line 2779 + 24 bytes
adding crash keyword. This seems to be new behaviour since the new tree control 
landed.
Keywords: crash
adding crash keyword
Adding topcrash keywork, made top10 talkback crash list today.
Keywords: topcrash
Summary: crash scrolling folder pane → crash scrolling folder pane [@ nsXULTreeOuterGroupFrame::FindPreviousRowContent]
fixed.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
This crash still happens in the latest builds. Atleast 10+ crashes are reported 
in the last 10 days.

nsXULTreeOuterGroupFrame::FindPreviousRowContent
Stack Trace: 
nsXULTreeOuterGroupFrame::FindPreviousRowContent
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsXULTreeOuterGroupFrame.cpp
nsXULTreeOuterGroupFrame::InternalPositionChanged
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsXULTreeOuterGroupFrame.cpp
nsXULTreeOuterGroupFrame::PositionChanged
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsXULTreeOuterGroupFrame.cpp
nsSliderFrame::SetCurrentPosition
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsSliderFrame.cpp
nsSliderFrame::HandleEvent
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsSliderFrame.cpp
PresShell::HandleEventInternal
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp
PresShell::HandleEvent
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp
nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp
nsViewManager2::DispatchEvent
[d:\builds\seamonkey\mozilla\view\src\nsViewManager2.cpp
HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp
nsWindow::DispatchEvent 
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp
nsWindow::DispatchWindowEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp
nsWindow::DispatchMouseEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp
ChildWindow::DispatchMouseEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp
nsWindow::ProcessMessage
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp
nsWindow::WindowProc 
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp
USER32.dll + 0x1820 (0x77e71820)
0x00f9009d

nsXULTreeOuterGroupFrame::FindPreviousRowContent 1cf70567

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/xul/base/src/nsXULTre
eOuterGroupFrame.cpp
line 838
Build: 2000072409 CrashDate: 2000-07-24 UptimeMinutes: 165 Total: 165 
OS: Windows NT 4.0 build 1381
URL: 
Comment: Crashed when scrolling in Mail
Stacktrace: http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=14725791

nsXULTreeOuterGroupFrame::FindPreviousRowContent 4907d116

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/xul/base/src/nsXULTre
eOuterGroupFrame.cpp
line 838
Build: 2000072409 CrashDate: 2000-07-24 UptimeMinutes: 16 Total: 68 
OS: Windows NT 5.0 build 2195
URL: 
Comment: scrolling "viciously" in the bookmarks manager (grab and drag up and
down rapidly).
Stacktrace: http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=14727639

nsXULTreeOuterGroupFrame::FindPreviousRowContent a13d3555

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/xul/base/src/nsXULTre
eOuterGroupFrame.cpp
line 838
Build: 2000072409 CrashDate: 2000-07-24 UptimeMinutes: 37 Total: 37 
OS: Windows NT 4.0 build 1381
URL: 
Comment: crash again with deleting the last message in thread pane and then
scrolling in the folder pane. Known bug reported. 7-24 am build. win32.
Stacktrace: http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=14729525

nsXULTreeOuterGroupFrame::FindPreviousRowContent 660a97b5

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/xul/base/src/nsXULTre
eOuterGroupFrame.cpp
line 838
Build: 2000072409 CrashDate: 2000-07-25 UptimeMinutes: 231 Total: 396 
OS: Windows NT 4.0 build 1381
URL: 
Comment: Crashed while scrolling in Mail
Stacktrace: http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=14767992

nsXULTreeOuterGroupFrame::FindPreviousRowContent 6f5baa51

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/xul/base/src/nsXULTre
eOuterGroupFrame.cpp
line 838
Build: 2000072409 CrashDate: 2000-07-25 UptimeMinutes: 108 Total: 108 
OS: Windows NT 4.0 build 1381
URL: 
Comment: 
Stacktrace: http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=14787009

nsXULTreeOuterGroupFrame::FindPreviousRowContent 233b26b5

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/xul/base/src/nsXULTre
eOuterGroupFrame.cpp
line 838
Build: 2000072421 CrashDate: 2000-07-25 UptimeMinutes: 54 Total: 54 
OS: Windows 98 4.10 build 67766446
URL: 
Comment: Opening IMAP "INBOX" after having selected another folder and not
waited for action to be finished.
Stacktrace: http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=14835330

nsXULTreeOuterGroupFrame::FindPreviousRowContent 5747ba5a

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/xul/base/src/nsXULTre
eOuterGroupFrame.cpp
line 838
Build: 2000072509 CrashDate: 2000-07-26 UptimeMinutes: 267 Total: 267 
OS: Windows NT 4.0 build 1381
URL: www.mirc-colors.com
Comment: trying to leave the page.
Stacktrace: http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=14851509

nsXULTreeOuterGroupFrame::FindPreviousRowContent eaada389

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/xul/base/src/nsXULTre
eOuterGroupFrame.cpp
line 838
Build: 2000072609 CrashDate: 2000-07-27 UptimeMinutes: 16 Total: 25 
OS: Windows NT 5.0 build 2195
URL: 
Comment: Scrolling the message pane in mail /news
Stacktrace: http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=14881982

nsXULTreeOuterGroupFrame::FindPreviousRowContent 11d4e2e6

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/xul/base/src/nsXULTre
eOuterGroupFrame.cpp
line 838
Build: 2000072509 CrashDate: 2000-07-25 UptimeMinutes: 4 Total: 4 
OS: Windows 98 4.10 build 67766222
URL: 
Comment: 
Stacktrace: http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=14882515

nsXULTreeOuterGroupFrame::FindPreviousRowContent cc949fc6

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/xul/base/src/nsXULTre
eOuterGroupFrame.cpp
line 838
Build: 2000072509 CrashDate: 2000-07-27 UptimeMinutes: 84 Total: 87 
OS: Windows NT 4.0 build 1381
URL: 
Comment: 
Stacktrace: http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=14889612

Status: RESOLVED → REOPENED
Resolution: FIXED → ---
FWIW, I no longer see this bug, but it only stopped happening last week, when
43374 was fixed. This would be consistent with the last talkback reports showing
this crash occuring on 7/27, when this 43374 was fixed.
adding myself and laurel to cc: list.  
nsbeta3+
Keywords: nsbeta3
Whiteboard: [nsbeta3+]
Target Milestone: --- → M18
Has anyone seen this since 7/27?  I haven't been able to get cyclone queries to
show any, so I must be doing something wrong, and now it seems to be down.
Whiteboard: [nsbeta3+] → [nsbeta3+] fixed along with 43374?
Mass-accepting.
Status: REOPENED → ASSIGNED
P1/Critical, but if nobody can reproduce it, or show evidence of it still
happening, and soon, then I'm going to resolve as WFM.
Severity: normal → critical
Priority: P3 → P1
Whiteboard: [nsbeta3+] fixed along with 43374? → [nsbeta3+] FIXED ALONG WITH 43374?
I did a cyclone query, and got a lot of matches for this, but none after 
08/15 (if I did the query right). Almost all of the ones I found had build ID 
080712, which I believe is the PR2 build ID. The comments mostly revolved 
around something to do with scrolling in trees (mail/ftp/bookmarks).

So:
1) This bug seems to be not occurring in recent builds
2) it wasn't fixed by bug 43374, as that fix went into the PR2 bits, yet 
   PR2 is hitting this crash a lot for people who downloaded it.

I also tried to reproduce this manually, but could not.
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
Reopening. Something has changed to start triggering this again. I hit this
today in the tree in the prefs panel. I then did a talkback query and found
44 recent talkback incidents, all with build ID after 08/28, almost all of
which had the (abbreviated) stack trace of : 

nsXULTreeOuterGroupFrame::FindPreviousRowContent 
                                     [nsXULTreeOuterGroupFrame.cpp, line 813]
nsXULTreeOuterGroupFrame::InternalPositionChanged 
                                     [nsXULTreeOuterGroupFrame.cpp, line 494] 
nsXULTreeOuterGroupFrame::PositionChanged 
                                     [nsXULTreeOuterGroupFrame.cpp, line 453] 
nsSliderFrame::SetCurrentPosition               [nsSliderFrame.cpp, line 701] 
nsSliderFrame::HandleEvent                      [nsSliderFrame.cpp, line 480] 
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Whiteboard: [nsbeta3+] FIXED ALONG WITH 43374? → [nsbeta3+]
Here is how to reproduce. With the default set of bookmarks for the commercial
build, open the bookmark manager. 

Expand most of the folders to get a scrollbar. Select one of the folder items
in the middle of the list (e.g. News and Sports). Make sure that the scrollbar 
thumb is neither at the top nor the bottom of the slider.

Now delete the selected folder (which also deletes the child bookmarks). You
should see the "white holes" have opened up in the tree rows. Now, grab the 
scrollbar thumb and yank it up and down. You should crash. 

(That seems contrived, but it is intended so hyatt can reproduce the crash 
easily. The other crashes occurred in various trees, and people were not always
clear on exactly how they had hit this state, but they were hitting it 
(including selmer, asa, phil in the email of the incidents)). 
PDT agrees P1
Whiteboard: [nsbeta3+] → [nsbeta3+][PDTP1]
I nailed it.  I found the core case that caused this again.
Status: REOPENED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
I just got this crash today in my debug build from this morning (9/21) with the 
exact same crash and with the exact same circumstances as bienvenu originally 
pointed out in the bug while scrolling my folder pane.

It seems like we could protect against the crash in a couple of ways:

  //Add a check for parent content some place in FindPreviousRowContent
  if(!parentContent)
    return 
  parentContent->GetTag(*getter_AddRefs(tag));
  if (tag && tag.get() == nsXULAtoms::tree) {
    // Hopeless. It ain't in there.
    return;
  }


Or in the calling function InternalPositionChanged, not call 
FindPreviousRowContent if rowContent is null. It may not solve the problem 
that's causing it, but at least it might prevent the crash.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
adding myself to cc.
It just happened to me again the next time I started up, so something must have 
broken recently since I had never had this crash before.
I'm guessing that nisheeth's async reflow landing has enabled the tree to get 
out of sync.  Yay. :)

*** Bug 53858 has been marked as a duplicate of this bug. ***
This is showing up prominently in talkback data since 2000-09-20-06.
mass-adding rtm keyword to all open nsbeta3+ xptoolkit bugs
Keywords: rtm
nsbeta3-, rtm+, possibly caused by asynch reflow
Whiteboard: [nsbeta3+][PDTP1] → [nsbeta3-][PDTP1][rtm+]
Should also be fixed with eric's landing.
Assignee: hyatt → evaughan
Status: REOPENED → NEW
PDT marking [rtm need info] until patch and code reviews are available.
Definitely want a fix for this though.
Whiteboard: [nsbeta3-][PDTP1][rtm+] → [nsbeta3-][PDTP1][rtm need info]
My current build fails when you try to delete bookmarks in this way it crashes 
in javascript somewhere. If I delete a header in the middle of mail it works 
with my new changes. Does this crash in the regular tree?
Status: NEW → ASSIGNED
You can also reproduce this as follows:

1) open mail
2) select a header in about the middle of the list
3) click on the sender header of mail to make it filter by sender.

Poof you crash. Same stack track.
I just got it crash exactly with the same stack while doing mail threading. 
Apparently we are dereferencing a null pointer - parentConten->GetTag(), line 
824. A defensive coding could prevent the hard crash. I'll be testing with the 
following patch.

Index: nsXULTreeOuterGroupFrame.cpp
===================================================================
RCS file: /cvsroot/mozilla/layout/xul/base/src/nsXULTreeOuterGroupFrame.cpp,v
retrieving revision 1.26
diff -c -r1.26 nsXULTreeOuterGroupFrame.cpp
*** nsXULTreeOuterGroupFrame.cpp        2000/09/20 23:10:48     1.26
--- nsXULTreeOuterGroupFrame.cpp        2000/10/03 21:43:49
***************
*** 765,770 ****
--- 765,771 ----
    }
    else if (aDownwardHint) {
      parentContent = dont_QueryInterface(aDownwardHint);
+     if (!parentContent) return;
      parentContent->ChildCount(index);
    }

***************
*** 778,783 ****
--- 779,785 ----
    for (PRInt32 i = index-1; i >= 0; i--) {
      nsCOMPtr<nsIContent> childContent;
      parentContent->ChildAt(i, *getter_AddRefs(childContent));
+     if (!childContent) return;
      nsCOMPtr<nsIAtom> tag;
      childContent->GetTag(*getter_AddRefs(tag));
      if (tag.get() == nsXULAtoms::treerow) {
***************
*** 803,808 ****
--- 805,811 ----
          for (j = childContentCount-1; j >= 0; j--) {

            childContent->ChildAt(j, *getter_AddRefs(grandChild));
+           if (!grandChild) return ;
            nsCOMPtr<nsIAtom> grandChildTag;
            grandChild->GetTag(*getter_AddRefs(grandChildTag));
            if (grandChildTag.get() == nsXULAtoms::treechildren)
***************
*** 822,827 ****
--- 825,831 ----
      }
    }

+   if (!parentContent) return;
    nsCOMPtr<nsIAtom> tag;
    parentContent->GetTag(*getter_AddRefs(tag));
    if (tag && tag.get() == nsXULAtoms::tree) {

-	parentContent	{...}
+	mRawPtr	0x00000000
+	tag	{...}
+	this	0x015226a4

nsXULTreeOuterGroupFrame::FindPreviousRowContent(int & 1, nsIContent * 
0x00000000, nsIContent * 0x00000000, nsIContent * * 0x0012f3c8) line 826 + 47 
bytes
nsXULTreeOuterGroupFrame::InternalPositionChanged(nsXULTreeOuterGroupFrame * 
const 0x015226a4, int 1, int 1) line 502 + 47 bytes
nsXULTreeOuterGroupFrame::PositionChanged(nsXULTreeOuterGroupFrame * const 
0x01522758, int 340, int 322) line 462
nsSliderFrame::SetCurrentPosition(nsIContent * 0x0792afa0, nsIFrame * 
0x01449ea0, int 322) line 701
nsSliderFrame::HandleEvent(nsSliderFrame * const 0x01522db4, nsIPresContext * 
0x05d8a110, nsGUIEvent * 0x0012f8c8, nsEventStatus * 0x0012f7b8) line 463
PresShell::HandleEventInternal(nsEvent * 0x0012f8c8, nsIView * 0x079587d0, 
unsigned int 1, nsEventStatus * 0x0012f7b8) line 4270 + 38 bytes
PresShell::HandleEvent(PresShell * const 0x05d8e3f4, nsIView * 0x079587d0, 
nsGUIEvent * 0x0012f8c8, nsEventStatus * 0x0012f7b8, int 1, int & 1) line 4190 + 
25 bytes
nsView::HandleEvent(nsView * const 0x079587d0, nsGUIEvent * 0x0012f8c8, unsigned 
int 28, nsEventStatus * 0x0012f7b8, int 1, int & 1) line 379
nsViewManager2::DispatchEvent(nsViewManager2 * const 0x05d8ecc0, nsGUIEvent * 
0x0012f8c8, nsEventStatus * 0x0012f7b8) line 1439
HandleEvent(nsGUIEvent * 0x0012f8c8) line 68
nsWindow::DispatchEvent(nsWindow * const 0x05d8e944, nsGUIEvent * 0x0012f8c8, 
nsEventStatus & nsEventStatus_eIgnore) line 681 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f8c8) line 702
nsWindow::DispatchMouseEvent(unsigned int 300, nsPoint * 0x00000000) line 3890 + 
21 bytes
ChildWindow::DispatchMouseEvent(unsigned int 300, nsPoint * 0x00000000) line 
4100
nsWindow::ProcessMessage(unsigned int 512, unsigned int 1, long 14025589, long * 
0x0012fc44) line 2937 + 24 bytes
nsWindow::WindowProc(HWND__ * 0x001905b8, unsigned int 512, unsigned int 1, long 
14025589) line 950 + 27 bytes
USER32! 77e7124c()
Attached patch a defensive fixSplinter Review
Yes but by aborting are we leaving the tree in the right state? Reassigning to 
hyatt to take a look at the patch.
Assignee: evaughan → hyatt
Status: ASSIGNED → NEW
I hit this crash yesterday, and continued past it with the debugger. In my case,
the tree was *not* in a good state, but it's probably better than crashing. I
think we should protect against the crash, since that's easy, and then try to
fix the underlying problem.
throw an assertion in there before the bulletproofing, so at least we can catch
it when it happens
I agree that we should bulletproof this with the assertion.  If anyone can
reproduce this with the null check, can you close the mail window and then open
it up again and have the folder tree work?  If so, the fact that you can recover
added to the fact that you wouldn't crash is a big plus.
yes, closing the mail window and re-opening it worked when I ran into this crash.
Waiting on eric's tree landing before I muck further with trees.
*** Bug 55654 has been marked as a duplicate of this bug. ***
According to today's list on n.p.m.crash-data, this is the #1 topcrash 
(excluding "MSVCRT.DLL", "msvcrt.dll", "libnecko.so", and "gkhtml.dll").
hi hyatt - has eric's tree landing happened yet?  thanks.
Yes, Eric's changes to the tree have landed.
I think this is still a topcrasher.

I think we should check in the defense patch,
but add some NS_ASSERTION(foo,"foo is null, see bug #44093");
everywhere we do the null checks.  that way it will still be a noticable bug in
debugs builds, not in release builds.

hyatt, if you are busy with other bugs and don't have the cycles to land this, I
can get a new patch (with the NS_ASSERTIONS()) and plead with the pdt to let me
check in.
Here is a real patch for this.  You don't need to null-check quite so much,
since retrieved children can never be null.  Also added assertions.

Status: NEW → ASSIGNED
Whiteboard: [nsbeta3-][PDTP1][rtm need info] → [nsbeta3-][PDTP1][rtm+]
Looking for an r= and a= from the mailnews guys for my patch.  Then pdt will ++
it I hope.
This is indeed still a topcrasher (#2 on the list behind 
nsXULDocument::ResumeWalk, excluding MSVCRT.DLL and gkhtml.dll crashes). 
Need an a=.  Alec?
adding mscott for possible super review.
sr=mscott. It'd be great to get this top crasher in rtm.
Ok, PDT, this is ready for you.
arg, would have sr'ed earlier if SERA wasn't so flakey!
*** Bug 56300 has been marked as a duplicate of this bug. ***
PDT says rtm++, please land on branch ASAP, but please do not include cleanup of
the commented out code.
Whiteboard: [nsbeta3-][PDTP1][rtm+] → [nsbeta3-][PDTP1][rtm++]
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
So, I'm seeing this assertion when I sort columns in the bookmarks manager.
Where should I start looking?
verified fixed -- talkback has no crashes for this stack since the patch 
went in, branch or trunk.
Status: RESOLVED → VERIFIED
Component: XP Toolkit/Widgets: Trees → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
Crash Signature: [@ nsXULTreeOuterGroupFrame::FindPreviousRowContent]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: