Closed
Bug 20508
Opened 25 years ago
Closed 25 years ago
[DOGFOOD][CRASH] Crashed after expanding folders and scrolling the scrollbar up/down from the folder pane
Categories
(SeaMonkey :: MailNews: Message Display, defect, P1)
SeaMonkey
MailNews: Message Display
Tracking
(Not tracked)
VERIFIED
FIXED
M12
People
(Reporter: huang, Assigned: alecf)
References
Details
(Whiteboard: [PDT+] 12/15)
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•25 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
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M12
Assignee | ||
Comment 2•25 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)
Updated•25 years ago
|
QA Contact: lchiang → nbaca
Comment 5•25 years ago
|
||
Setting QA Contact to nbaca.
Reporter | ||
Comment 6•25 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!!
Reporter | ||
Updated•25 years ago
|
OS: Linux → All
Hardware: PC → All
Reporter | ||
Comment 8•25 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•25 years ago
|
Priority: P3 → P1
Assignee | ||
Comment 9•25 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•25 years ago
|
||
*** Bug 20641 has been marked as a duplicate of this bug. ***
Assignee | ||
Updated•25 years ago
|
Whiteboard: [PDT+] → [PDT+] 12/7
Assignee | ||
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•25 years ago
|
Status: RESOLVED → REOPENED
Assignee | ||
Comment 11•25 years ago
|
||
oops, marked the wrong bug fixed.
Assignee | ||
Updated•25 years ago
|
Status: REOPENED → ASSIGNED
Assignee | ||
Updated•25 years ago
|
Resolution: FIXED → ---
Assignee | ||
Comment 12•25 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•25 years ago
|
Whiteboard: [PDT+] 12/7 → [PDT+] 12/8
Assignee | ||
Comment 13•25 years ago
|
||
this will have to wait until tomorrow.
Assignee | ||
Updated•25 years ago
|
Whiteboard: [PDT+] 12/8 → [PDT+] 12/13
Assignee | ||
Comment 14•25 years ago
|
||
Been caught up in #18420, didn't get a chance to tackle this yet.
Updated•25 years ago
|
Whiteboard: [PDT+] 12/13 → [PDT+] 12/15
Assignee | ||
Comment 15•25 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•25 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•25 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•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 18•25 years ago
|
||
fix checked in.
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 19•25 years ago
|
||
Build 1999121612M12: NT4, Linux
Build 1999121615M12: Mac 8.5.1
Verified Fixed. Thanks!
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•