20508 - [DOGFOOD][CRASH] Crashed after expanding folders and scrolling the scrollbar up/down from the folder pane

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Message Display, defect, P1)

Description

[Karen Huang]

Based bug#13483 Lisa's comments, open new bug as following:

Linux build: 12-01-08-M12

Crashed after expanding folders and scrolling the scrollbar up/down from the
folder pane

1) Login to an IMAP account and open mail folders
2) Expand all folders from the folder pane, scrollbar displayed.
3) Tried to scroll up by using the folder pane scrollbar, crashed.
4) Actual Results: Crashed, see talkback#1562438, 1569684

Expected Results: Should scroll up successfully without crash!

#1569684:

 Stack Trace

libraptorview.so + 0x1005c (0x40dfb05c)
libraptorview.so + 0x5f4d (0x40df0f4d)
libwidget_gtk.so + 0x31b8a (0x404c3b8a)
libwidget_gtk.so + 0x31ab5 (0x404c3ab5)
libwidget_gtk.so + 0x31c10 (0x404c3c10)
libwidget_gtk.so + 0x3206e (0x404c406e)
libwidget_gtk.so + 0x351bc (0x404c71bc)
libwidget_gtk.so + 0x28ffa (0x404baffa)
libgdk-1.2.so.0 + 0x170fb (0x406190fb)
libglib-1.2.so.0 + 0xfa86 (0x40646a86)
libglib-1.2.so.0 + 0x10041 (0x40647041)
libglib-1.2.so.0 + 0x101e1 (0x406471e1)
libgtk-1.2.so.0 + 0x8b7a9 (0x405707a9)
libwidget_gtk.so + 0x218d5 (0x404b38d5)
libnsappshell.so + 0x112d2 (0x403692d2)
mozilla-bin + 0x25d5 (0x0804a5d5)
mozilla-bin + 0x2780 (0x0804a780)
libc.so.6 + 0x17cb3 (0x401f4cb3)

#1562438:

 Stack Trace

0x08a9e714
libraptorview.so + 0x5f4d (0x407f0f4d)
libwidget_gtk.so + 0x31b8a (0x41348b8a)
libwidget_gtk.so + 0x31ab5 (0x41348ab5)
libwidget_gtk.so + 0x31c10 (0x41348c10)
libwidget_gtk.so + 0x3206e (0x4134906e)
libwidget_gtk.so + 0x351bc (0x4134c1bc)
libwidget_gtk.so + 0x28ffa (0x4133fffa)
libgdk-1.2.so.0 + 0x170fb (0x406b10fb)
libglib-1.2.so.0 + 0xfa86 (0x406dea86)
libglib-1.2.so.0 + 0x10041 (0x406df041)
libglib-1.2.so.0 + 0x101e1 (0x406df1e1)
libgtk-1.2.so.0 + 0x8b7a9 (0x406087a9)
libwidget_gtk.so + 0x218d5 (0x413388d5)
libnsappshell.so + 0x112d2 (0x411c72d2)
mozilla-bin + 0x25d5 (0x0804a5d5)
mozilla-bin + 0x2780 (0x0804a780)
libc.so.6 + 0x17cb3 (0x401f4cb3)

Will try POP & Windows, Mac later...

Comment 1

[Phil Peterson]

Reassign to alecf, nominate for dogfood as bug 13483 was

Comment 2

[Alec Flett]

argh, yeah, this is bad, but very different from that bug...(so nobody mark it
dupe) this looks like we're getting the view scrollbars rather than the tree's
own scrollbar. This can probably be fixed w/XUL (as AIM was fixed yesterday)

Comment 3

[Phil Peterson]

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

Comment 4

[Phil Peterson]

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

Comment 5

[Ninoschka Baca]

Setting QA Contact to nbaca.

Comment 6

[Karen Huang]

Cc: phil
Sorry!! My Bugzilla stalled & had problem from Linux when I submitted,
so that's why you saw 3 times writing the same bug. Sorry about that!!

Comment 7

[leger]

Putting on PDT+ radar

Comment 8

[Karen Huang]

Copied/Pasted more follow-up from the comments from bug#20510
since this bug will be the main bug to fix,
also changed platforms/OS to ALL since it apply to all the platforms!!

-----------------------------------------------

Crashed again on WinNT build 12-01-09-M12.

Talkback# 1587154:
nsViewManager::DispatchEvent
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 1650]
HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 69]
nsWindow::DispatchEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 441]
nsWindow::DispatchWindowEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 458]
nsWindow::DispatchMouseEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3466]
ChildWindow::DispatchMouseEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3682]
nsWindow::ProcessMessage
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 2774]
nsWindow::WindowProc
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 625]
USER32.dll + 0x1820 (0x77e71820)
0x0127009f

------- Additional Comments From [e-mail]  12/01/99 14:19 -------
Crashed on WinNT/POP, too -> Problem not only happened on IMAP.

talkback#1589291:
nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 792]
nsViewManager::DispatchEvent
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 1678]
HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 69]
nsWindow::DispatchEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 441]
nsWindow::DispatchWindowEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 458]
nsWindow::DispatchMouseEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3466]
ChildWindow::DispatchMouseEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3682]
nsWindow::ProcessMessage
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 2774]
nsWindow::WindowProc
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 625]
USER32.dll + 0x1820 (0x77e71820)
0x0087009e

Comment 9

[Alec Flett]

so it looks like my fix for #13483 has stopped working.... the scrollbar isn't
going away when the children are collapsed. The code is there, but the reflows
have changed behavior... I'll see what I can do to make the previous fix a
little more aggresive about destroying the scrollbar.

Comment 10

[Alec Flett]

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

Comment 11

[Alec Flett]

oops, marked the wrong bug fixed.

Comment 12

[Alec Flett]

ok, I figured out what happened: my fix last week only worked because there was
an extra reflow in the table. Someone was smart enough to fix this, and thus my
bug broke. Before, I was counting the number of visible frames, and there
happened to be one reflow where the frames had not gone away, but the content
had... thus when I did the comparison, the old frames were still around so I
could tell that there was enough room on screen for the content...

Without that extra reflow, I now get notified only when the old frames have
already gone away, which means that I don't know how many frames will fit in the
tree view. When it gets to ReflowAfterRowLayout, the frames have already been
destroyed, so the number of visible row frames is less than the number of
content rows, so the tree doesn't think it needs to scroll.

I need to talk to hyatt more about this today.

Comment 13

[Alec Flett]

this will have to wait until tomorrow.

Comment 14

[Alec Flett]

Been caught up in #18420, didn't get a chance to tackle this yet.

Comment 15

[Alec Flett]

ahah! I figured out how to tell when you're removing rows because of content
going away! In OnContentInserted, you can get the rowcount of the frame that's
being destroyed, so then you know that there is probably room for rowcount rows.

I think we can store this somewhere as the 'potential number of rows' that could
be stored in the view. Then we can do our little magic to determine if we need
to scroll to position 0.

even if we the 'potential' number is wrong (for instance, if a few rows are
really tall) scrolling to zero might not be too bad. We'll see.
More on this tomorrow.

Comment 16

[Alec Flett]

the other thing is that you'd want to save this value only until
ReflowAfterRowLayout, so that it doesn't get stale as the user does stuff with
the tree.

Comment 17

[Alec Flett]

ok, I've got the fix in hand, got it reviewed by hyatt
the actual fix ended up being basically the same as for #21471, so I think I can
get both in one shot.

Comment 18

[Alec Flett]

fix checked in.

Comment 19

[Ninoschka Baca]

Build 1999121612M12: NT4, Linux
Build 1999121615M12: Mac 8.5.1
Verified Fixed. Thanks!