16929 - [DOGFOOD][Tree][PP]Linux: crash 1/2 the time when drag scroll bar in folder many times

Status: VERIFIED FIXED

(MailNews Core :: Backend, defect, P1)

Description

[fenella]

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.

Comment 1

[fenella]

Linux (1999-10-21-08 M11) commercial
Crash is still there in this build.

Comment 2

[Phil Peterson]

Reassign to alecf and nominate for dogfood.

Comment 3

[leger]

Putting on PDT+ radar.

Comment 4

[daver]

Alec, What's the update on this one?

Comment 5

[Alec Flett]

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.

Comment 6

[Alec Flett]

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?

Comment 7

[fenella]

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.

Comment 8

[Alec Flett]

This should be fixed with my latest tree checkin.

Comment 9

[fenella]

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

[lchiang]

Fenella, this bug is marked M12 target milestone with "partial fixed applied in
m11".  Can you retest this with M12 builds?

Comment 11

[Alec Flett]

yes, the fix went into M12.
Marking fixed.

Comment 12

[fenella]

Sure. I will re-test this in the M12 build. thanks.

Comment 13

[fenella]

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

Comment 14

[Alec Flett]

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.

Comment 15

[Alec Flett]

Eric/David - do either of you have any wisdom for me? :)
(Read my last comment)

Comment 16

[Alec Flett]

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)

Comment 17

[Alec Flett]

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.

Comment 18

[Alec Flett]

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...

Comment 19

[Alec Flett]

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

Comment 20

[Alec Flett]

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

Comment 21

[Alec Flett]

updating PDT+ date because this is the highest priority on my list

Comment 22

[Alec Flett]

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)

Comment 23

[Alec Flett]

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.

Comment 24

[Alec Flett]

Attachment: Initial attempt (needs to be looked at by hyatt)

Comment 25

[Alec Flett]

adding new patch against today's tree.

Comment 26

[Alec Flett]

Attachment: Updated patch (smaller)

Comment 27

[Alec Flett]

I missed hyatt today, will get this in tomorrow.

Comment 28

[Alec Flett]

fix checked in!

Comment 29

[fenella]

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

[scalkins]

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.

Comment 31

[Alex Musil]

No need to make this confidential.

Comment 32

[scalkins]

Talkback trace from scrolling through standalone buddy list follows:
Incident ID 1552814
 Trigger Time
               1999-11-30 14:53:33
 Email Address
               [e-mail]
 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

Comment 33

[Alec Flett]

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)

Comment 34

[Pulsebot]

Pushed by ffxbld-merge:
https://hg.mozilla.org/releases/mozilla-beta/rev/000f8be60965
[fenix] support-rc-versions (https://github.com/mozilla-mobile/fenix/pull/16929)