If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

VERIFIED FIXED in M12

Status

SeaMonkey
MailNews: Message Display
P1
critical
VERIFIED FIXED
18 years ago
13 years ago

People

(Reporter: Karen Huang, Assigned: Alec Flett)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDT+] 12/15)

(Reporter)

Description

18 years ago
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...

Updated

18 years ago
Assignee: phil → alecf
Summary: [CRASH] Crashed after expanding folders and scrolling the scrollbar up/down from the folder pane → [DOGFOOD][CRASH] Crashed after expanding folders and scrolling the scrollbar up/down from the folder pane

Comment 1

18 years ago
Reassign to alecf, nominate for dogfood as bug 13483 was
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
Target Milestone: M12
(Assignee)

Comment 2

18 years ago
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

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

Comment 4

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

Updated

18 years ago
QA Contact: lchiang → nbaca

Comment 5

18 years ago
Setting QA Contact to nbaca.
(Reporter)

Comment 6

18 years ago
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!!

Updated

18 years ago
Whiteboard: [PDT+]

Comment 7

18 years ago
Putting on PDT+ radar
(Reporter)

Updated

18 years ago
OS: Linux → All
Hardware: PC → All
(Reporter)

Comment 8

18 years ago
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 huang@netscape.com  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
(Assignee)

Updated

18 years ago
Priority: P3 → P1
(Assignee)

Comment 9

18 years ago
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.
(Assignee)

Comment 10

18 years ago
*** Bug 20641 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

18 years ago
Whiteboard: [PDT+] → [PDT+] 12/7
(Assignee)

Updated

18 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
(Assignee)

Updated

18 years ago
Status: RESOLVED → REOPENED
(Assignee)

Comment 11

18 years ago
oops, marked the wrong bug fixed.
(Assignee)

Updated

18 years ago
Status: REOPENED → ASSIGNED
(Assignee)

Updated

18 years ago
Resolution: FIXED → ---
(Assignee)

Comment 12

18 years ago
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.
(Assignee)

Updated

18 years ago
Whiteboard: [PDT+] 12/7 → [PDT+] 12/8
(Assignee)

Comment 13

18 years ago
this will have to wait until tomorrow.
(Assignee)

Updated

18 years ago
Whiteboard: [PDT+] 12/8 → [PDT+] 12/13
(Assignee)

Comment 14

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

Updated

18 years ago
Blocks: 21564

Updated

18 years ago
Whiteboard: [PDT+] 12/13 → [PDT+] 12/15
(Assignee)

Comment 15

18 years ago
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.
(Assignee)

Comment 16

18 years ago
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.
(Assignee)

Comment 17

18 years ago
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.
(Assignee)

Updated

18 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED
(Assignee)

Comment 18

18 years ago
fix checked in.

Updated

18 years ago
Status: RESOLVED → VERIFIED

Comment 19

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

Updated

18 years ago
Blocks: 22176

Updated

18 years ago
No longer blocks: 21564

Updated

18 years ago
No longer blocks: 22176
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.