Closed
Bug 16929
Opened 25 years ago
Closed 25 years ago
[DOGFOOD][Tree][PP]Linux: crash 1/2 the time when drag scroll bar in folder many times
Categories
(MailNews Core :: Backend, defect, P1)
Tracking
(Not tracked)
VERIFIED
FIXED
M12
People
(Reporter: fenella, Assigned: alecf)
References
Details
(Whiteboard: [PDT+] partial fix applied in m11 - 11/23)
Attachments
(2 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review |
Linux (1999-10-20-11 M11) commercial
1. Launch Messenger (using ./mozilla-apprunner.sh -mail) (either single POP or
IMAP)
2. Expand folders in the folder pane to force the scroll bar to display
3. Keep expanding folders, then click on the down arrow to display the bottom
of the folder pane.
4. Click on the newsserver (news.mozilla.org) to open the news group
5. Close the folders from the bottom of the folder pane.
6. Click on the up arrow to go back to the top folder
Actual result: It crashes here after step 6. But no core file
Expected result: It should not crash
This problem only occurs on Linux. Consistently reproducible.
Linux (1999-10-21-08 M11) commercial
Crash is still there in this build.
Updated•25 years ago
|
Assignee: phil → alecf
Summary: [PP]Linux only: crash when drag scroll bar in folder many times → [DOGFOOD][PP]Linux only: crash when drag scroll bar in folder many times
Comment 2•25 years ago
|
||
Reassign to alecf and nominate for dogfood.
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M11
Assignee | ||
Comment 5•25 years ago
|
||
We shouldn't hold M11 for this, but I'm going to keep this M11 for a day or so
and try to focus on it.
Assignee | ||
Updated•25 years ago
|
Target Milestone: M11 → M12
Assignee | ||
Updated•25 years ago
|
Summary: [DOGFOOD][PP]Linux only: crash when drag scroll bar in folder many times → [DOGFOOD][Tree][PP]Linux only: crash when drag scroll bar in folder many times
Assignee | ||
Comment 6•25 years ago
|
||
I may have fixed this with some of my checkins in the last day or so. Fenella -
can you try again, and see if you can get it to crash?
Assignee | ||
Updated•25 years ago
|
Priority: P3 → P1
Linux Redhat 6.0 (1999-11-05-08 M11)
I have tried this 6 times on IMAP, 3 times it crashes. The other 3 times were
fine.
Try it 2 time on POP, crashes 50% of the time.
Updated•25 years ago
|
Summary: [DOGFOOD][Tree][PP]Linux only: crash when drag scroll bar in folder many times → [DOGFOOD][Tree][PP]Linux: crash 1/2 the time when drag scroll bar in folder many times
Whiteboard: [PDT+] → [PDT+] partcial fix applied in m11
Updated•25 years ago
|
Whiteboard: [PDT+] partcial fix applied in m11 → [PDT+] partial fix applied in m11 - 12/3
Assignee | ||
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 8•25 years ago
|
||
This should be fixed with my latest tree checkin.
Linux (1999-11-12-18 M11) commercial
IMAP: I repeated the steps in the original report 4 time. No problem on IMAP, it
does not crash any more
POP: Out of 4 times I tried on POP, it crashed 3 times.
Reopen it for POP only
Comment 10•25 years ago
|
||
Fenella, this bug is marked M12 target milestone with "partial fixed applied in
m11". Can you retest this with M12 builds?
Assignee | ||
Updated•25 years ago
|
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 11•25 years ago
|
||
yes, the fix went into M12.
Marking fixed.
Reporter | ||
Comment 12•25 years ago
|
||
Sure. I will re-test this in the M12 build. thanks.
Reporter | ||
Comment 13•25 years ago
|
||
Linux (1999-11-115-12 M12) commercial
IMAP: no problem and no crash.
POP: sorry, I still see the crash on the M12 build. Alecf, I can show you the
crash.
thanks, fenella
Assignee | ||
Comment 14•25 years ago
|
||
What seems to be happening now is that the scrollbar goes away because we've
scrolled up to the top, but the mouse button is still down. When it's released,
a mouseup event gets generated, but the scrollbar is not there anyway.
I have to figure out where the scrollbar is getting destroyed, and maybe somehow
schedule it's destruction for later. Not sure how to do this though.
adding hyatt and evaughn for any comments about how to do this.
Assignee | ||
Comment 15•25 years ago
|
||
Eric/David - do either of you have any wisdom for me? :)
(Read my last comment)
Assignee | ||
Comment 16•25 years ago
|
||
here's a stacktrace, BTW. notice that frame 0 is some wierd pointer. I think
this object has long been deleted/freed (AnonymousElements don't refcount their
parents of course, so I think the parent has already gone away)
#0 0x8acce4d in ?? ()
#1 0x40dd432b in AnonymousElement::GetParent (this=0x8aceee8,
aResult=@0xbfffec60) at nsScrollbarFrame.cpp:74
#2 0x40d5f19e in nsCSSFrameConstructor::FindPrimaryFrameFor (this=0x862afb8,
aPresContext=0x86f8460, aFrameManager=0x84ec0d0, aContent=0x8aceef4,
aFrame=0xbfffed04) at nsCSSFrameConstructor.cpp:7824
#3 0x40e1ee6e in StyleSetImpl::FindPrimaryFrameFor (this=0x84cbad8,
aPresContext=0x86f8460, aFrameManager=0x84ec0d0, aContent=0x8aceef4,
aFrame=0xbfffed04) at nsStyleSet.cpp:1050
#4 0x40c59d81 in FrameManager::GetPrimaryFrameFor (this=0x84ec0d0,
aContent=0x8aceef4, aResult=0xbfffed04) at nsFrameManager.cpp:419
#5 0x40c7b589 in PresShell::GetPrimaryFrameFor (this=0x87ae8b8,
aContent=0x8aceef4, aResult=0xbfffed04) at nsPresShell.cpp:2207
#6 0x40d5cdd3 in nsCSSFrameConstructor::ContentStatesChanged (this=0x862afb8,
aPresContext=0x86f8460, aContent1=0x0, aContent2=0x8aceef4)
at nsCSSFrameConstructor.cpp:6789
#7 0x40e1ed27 in StyleSetImpl::ContentStatesChanged (this=0x84cbad8,
aPresContext=0x86f8460, aContent1=0x8a336b0, aContent2=0x8aceef4)
at nsStyleSet.cpp:981
#8 0x40c7afb5 in PresShell::ContentStatesChanged (this=0x87ae8b8,
aDocument=0x87ead00, aContent1=0x8a336b0, aContent2=0x8aceef4)
at nsPresShell.cpp:2020
#9 0x407fa9c8 in nsXULDocument::ContentStatesChanged (this=0x87ead00,
aContent1=0x8a336b0, aContent2=0x8aceef4) at nsXULDocument.cpp:1127
#10 0x40c40a7c in nsEventStateManager::SetContentState (this=0x88f4018,
aContent=0x8a336b0, aState=4) at nsEventStateManager.cpp:1692
#11 0x40c3ec43 in nsEventStateManager::GenerateMouseEnterExit (this=0x88f4018,
aPresContext=@0x86f8460, aEvent=0xbffff234) at nsEventStateManager.cpp:901
#12 0x40c3c9cd in nsEventStateManager::PreHandleEvent (this=0x88f4018,
aPresContext=@0x86f8460, aEvent=0xbffff234, aTargetFrame=0x8a603d8,
aStatus=@0xbffff148, aView=0x870eb98) at nsEventStateManager.cpp:176
#13 0x40c7be06 in PresShell::HandleEvent (this=0x87ae8b8, aView=0x870eb98,
aEvent=0xbffff234, aEventStatus=@0xbffff148) at nsPresShell.cpp:2398
#14 0x40fe5044 in nsView::HandleEvent (this=0x870eb98, event=0xbffff234,
aEventFlags=28, aStatus=@0xbffff148, aHandled=@0xbffff0dc)
at nsView.cpp:839
#15 0x40fee67a in nsViewManager::DispatchEvent (this=0x873f2e8,
aEvent=0xbffff234, aStatus=@0xbffff148) at nsViewManager.cpp:1722
#16 0x40fe3a4d in HandleEvent (aEvent=0xbffff234) at nsView.cpp:68
#17 0x404f2ccc in ?? () from /home1/alecf/xpc/mozilla/dist/bin/libwidget_gtk.so
#18 0x404f2ad9 in ?? () from /home1/alecf/xpc/mozilla/dist/bin/libwidget_gtk.so
#19 0x404f2d52 in ?? () from /home1/alecf/xpc/mozilla/dist/bin/libwidget_gtk.so
#20 0x404f33ee in ?? () from /home1/alecf/xpc/mozilla/dist/bin/libwidget_gtk.so
#21 0x404f3f80 in ?? () from /home1/alecf/xpc/mozilla/dist/bin/libwidget_gtk.so
#22 0x4060dc49 in ?? () from /usr/lib/libgtk-1.2.so.0
#23 0x405cf935 in ?? () from /usr/lib/libgtk-1.2.so.0
(etc)
Assignee | ||
Updated•25 years ago
|
Status: REOPENED → ASSIGNED
Assignee | ||
Comment 17•25 years ago
|
||
ok, I think #18369, #18713, and #16929 are all related to the scrollbar going
away due to a tree reflow, and then recieving events, probably all mouseups.
Assignee | ||
Comment 18•25 years ago
|
||
ok, it seems the least that could be done would somehow to call
SetParent(nsnull) on the anonymous nodes when the scrollbar frame goes
away...but I can't figure out where the appropriate place would be.
I'm going to try doing it in nsScrollbarFrame's destructor...
Assignee | ||
Comment 19•25 years ago
|
||
*** Bug 18369 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 20•25 years ago
|
||
*** Bug 18713 has been marked as a duplicate of this bug. ***
Assignee | ||
Updated•25 years ago
|
Whiteboard: [PDT+] partial fix applied in m11 - 12/3 → [PDT+] partial fix applied in m11 - 11/19
Assignee | ||
Comment 21•25 years ago
|
||
updating PDT+ date because this is the highest priority on my list
Assignee | ||
Comment 22•25 years ago
|
||
ok, the fix I talked with hyatt is this: if at any point we collapse enough
treerows such that the total number of rows is less than the total number of
visible rows, then we scroll to the top and kill the scrollbar.... this way the
scrollbar can never disappear beneath the user while he's scrolling, because
should go away before that ever happens.
Hoping to get a the fix in today (it's about half done)
Assignee | ||
Comment 23•25 years ago
|
||
ok, I'm attaching a potential fix for this....(it happens to include other fixes
that will probably get checked in tonight, so watch for conflicts - when some of
these fixes go in, I'll attach an updated patch)
Unfortunately, I need to run this by hyatt because I'm not sure I'm doing the
right thing..this seems to be causing many excess reflows, but it might just be
me.
Note that this fix actually prevents the user from doing what is described in
the bug - i.e. instead of fixing the scrolling problem, I'm repositioning the
tree so the scrollbar goes away when you remove enough items such that all items
will fit in the tree.
Assignee | ||
Comment 24•25 years ago
|
||
Assignee | ||
Updated•25 years ago
|
Whiteboard: [PDT+] partial fix applied in m11 - 11/19 → [PDT+] partial fix applied in m11 - 11/22
Assignee | ||
Comment 25•25 years ago
|
||
adding new patch against today's tree.
Assignee | ||
Comment 26•25 years ago
|
||
Assignee | ||
Updated•25 years ago
|
Whiteboard: [PDT+] partial fix applied in m11 - 11/22 → [PDT+] partial fix applied in m11 - 11/23
Assignee | ||
Comment 27•25 years ago
|
||
I missed hyatt today, will get this in tomorrow.
Assignee | ||
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 28•25 years ago
|
||
fix checked in!
Reporter | ||
Comment 29•25 years ago
|
||
Linux (1999-11-24-08 M12) commercial
Using the same scenario to re-test this bug on both POP and IMAP. No more
crash.
Comment 30•25 years ago
|
||
Reopening. Setting to Confidential.
This is still crashing in the AIM Standalone when scrolling through the buddy
list in todays build 1999-11-30-08 M12-(Linux). Please stop by my cube if you
need to see it.Had problems connecting to talkback server, but will supply trace
if different from the one above when I can access it.
Updated•25 years ago
|
Group: netscapeconfidential?
Comment 31•25 years ago
|
||
No need to make this confidential.
Comment 32•25 years ago
|
||
Talkback trace from scrolling through standalone buddy list follows:
Incident ID 1552814
Trigger Time
1999-11-30 14:53:33
Email Address
scalkins@netscape.com
User Comments
Crash scrolling through standalone
Build ID
1999112909
Product ID
Communicator5.0
Platform ID
Win32
Stack Trace
nsFrame::SetRect [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrame.cpp,
line 502]
nsXULDocument::StyleRuleRemoved
[d:\builds\seamonkey\mozilla\rdf\content\src\nsXULDocument.cpp, line 1447]
nsXULElement::UnsetAttribute
[d:\builds\seamonkey\mozilla\rdf\content\src\nsXULElement.cpp, line 2303]
nsSliderFrame::AppendFrames
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsSliderFrame.cpp, line 769]
nsSliderFrame::CurrentPositionChanged
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsSliderFrame.cpp, line 625]
PresShell::Scrolled
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 2487]
nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 841]
nsViewManager::DispatchEvent
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 1725]
HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 69]
nsWindow::DispatchEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 442]
nsWindow::DispatchWindowEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 459]
nsWindow::DispatchMouseEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3541]
nsWindow::ShowMenuBar
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3801]
nsWindow::ProcessMessage
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3025]
nsWindow::WindowProc
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 626]
USER32.dll + 0x1820 (0x77e71820)
0x008900b0
Assignee | ||
Updated•25 years ago
|
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 33•25 years ago
|
||
ah! a VERY different stack trace - let's file a new bug (mainly because alot of
work went into fixing THIS bug and I'd like to see it recorded)
Updated•20 years ago
|
Product: MailNews → Core
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•