110145 - Using the mouse wheel crashes when there's no target content - Trunk [@ nsEventStateManager::DoWheelScroll]

Status: VERIFIED FIXED

(Core :: XUL, defect)

Description

[eberry]

Build: 2001111403 under W2K
Go to http://slashdot.org
File, Print Preview
Use the mouse wheel to scroll up and down a bit in the preview
A crash usually happens very quickly
Talkback reports: TB38018671Y, TB38018640K

CC: stephend talkback stack help

Comment 1

[sujay]

is this related to bug 109567 ?

Comment 2

[eberry]

See also recent mouse wheel bug 110101 (possibly related)

Comment 3

[Diego Biurrun]

wfm, linux yesterday's CVS build but crashes 2001111408 ---> NEW

Comment 4

[Matthias Versen [:Matti]]

win2k stack trace:
nsEventStateManager::DoWheelScroll(nsIPresContext * 0x04c1fd80, nsIFrame * 
0x04c3d5f0, nsMouseScrollEvent * 0x0012f6c8, int 5, int 0, int 0) line 1220 + 47 
bytes
nsEventStateManager::PostHandleEvent(nsEventStateManager * const 0x04c3ca30, 
nsIPresContext * 0x04c1fd80, nsEvent * 0x0012f6c8, nsIFrame * 0x04c3d5f0, 
nsEventStatus * 0x0012f520, nsIView * 0x04c3ea90) line 1613
PresShell::HandleEventInternal(nsEvent * 0x0012f6c8, nsIView * 0x04c3ea90, 
unsigned int 1, nsEventStatus * 0x0012f520) line 5835 + 43 bytes
PresShell::HandleEvent(PresShell * const 0x04c2097c, nsIView * 0x04c3ea90, 
nsGUIEvent * 0x0012f6c8, nsEventStatus * 0x0012f520, int 0, int & 1) line 5740 + 
25 bytes
nsView::HandleEvent(nsView * const 0x04c3ea90, nsGUIEvent * 0x0012f6c8, unsigned 
int 8, nsEventStatus * 0x0012f520, int 0, int & 1) line 375
nsView::HandleEvent(nsView * const 0x04c3e9b0, nsGUIEvent * 0x0012f6c8, unsigned 
int 8, nsEventStatus * 0x0012f520, int 0, int & 1) line 348
nsView::HandleEvent(nsView * const 0x04c3e4a0, nsGUIEvent * 0x0012f6c8, unsigned 
int 8, nsEventStatus * 0x0012f520, int 0, int & 1) line 348
nsView::HandleEvent(nsView * const 0x04c21040, nsGUIEvent * 0x0012f6c8, unsigned 
int 28, nsEventStatus * 0x0012f520, int 1, int & 1) line 348
nsViewManager::DispatchEvent(nsViewManager * const 0x04c20e00, nsGUIEvent * 
0x0012f6c8, nsEventStatus * 0x0012f520) line 1874
HandleEvent(nsGUIEvent * 0x0012f6c8) line 84
nsWindow::DispatchEvent(nsWindow * const 0x04c3e86c, nsGUIEvent * 0x0012f6c8, 
nsEventStatus & nsEventStatus_eIgnore) line 744 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f6c8) line 765
nsWindow::ProcessMessage(unsigned int 522, unsigned int 4287102976, long 
33096187, long * 0x0012fce4) line 3790 + 24 bytes
nsWindow::ProcessMessage(unsigned int 522, unsigned int 4287102976, long 
33096187, long * 0x0012fce4) line 3760 + 33 bytes
nsWindow::WindowProc(HWND__ * 0x0009031a, unsigned int 522, unsigned int 
4287102976, long 33096187) line 1012 + 27 bytes
USER32! 77e02e98()
USER32! 77e030e0()
USER32! 77e05824()
nsAppShellService::Run(nsAppShellService * const 0x03906da0) line 303
main1(int 2, char * * 0x003526f0, nsISupports * 0x00000000) line 1304 + 32 bytes
main(int 2, char * * 0x003526f0) line 1630 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e87d08()

Comment 5

[Olivier Cahagne]

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

Comment 6

[David Einstein]

Attachment: Patch for bad event handling

This is the patch from bug 110193.  It fixes the outward manifestations of this
bug 
as well, which is not surprising as they have the same stack trace.  I'm not
duping them together because while I understand why we get no content in bug
11093, I'm not sure that we should be getting it here.

Comment 7

[Blake Ross]

This crashes whenever you mousewheel over something outside of the Mozilla
window (e.g. the Windows taskbar) when Mozilla is open.  The patch seems right
given the circumstances, but why did this only crop up recently?

Comment 8

[Blake Ross]

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

Comment 9

[Blake Ross]

Oh, hewitt just added this code yesterday.

Comment 10

[Blake Ross]

Comment on attachment 57922 [details] [diff] [review]
Patch for bad event handling

sr=blake

Comment 11

[Brian Ryner (not reading)]

Hm, shouldn't we be catching this at the widget level and not even dispatching
an event?

Comment 12

[Blake Ross]

I don't think so.  For example, in OE, focusing the thread pane, putting the
cursor outside the window, and then mousewheel scrolling will still scroll the
thread pane. So I think one day we might want this.

Comment 13

[Brian Ryner (not reading)]

Oh, ok.  In that case, maybe we should make sure to always fall back to the
focused content, instead of bailing?  It's open to debate... on some platforms
it's not even possible to get mousewheel events originating outside your window.

Comment 14

[greer]

Seeing on the topcrash lists. Updating stuff for talkback.

Comment 15

[Blake Ross]

As far as Windows goes, it looks like most things (native trees, textboxes
[notepad], folders, and dropdowns) scroll in this manner, so if someone wants to
do that as part of this bug, sure. We should get some fix in for tomorrow,
though, it's crashing me all over the place.

Comment 16

[Jay Patel [:jay]]

adding topcrash keyword and Trunk [@ nsEventStateManager::DoWheelScroll] to
summary for tracking, this crash has shown up on the topcrash list for the
MozillaTrunk as of today:

nsEventStateManager::DoWheelScroll   35 
BBID range: 38017202 - 38034631
Min/Max Seconds since last crash: 6 - 10152
Min/Max Runtime: 23 - 15880
Crash data range: 2001-11-14 to 2001-11-14
Build ID range: 2001111408 to 2001111410
Keyword List : 
Stack Trace: 

	 nsEventStateManager::DoWheelScroll()
	 nsEventStateManager::PostHandleEvent()
	 PresShell::HandleEventInternal()
	 PresShell::HandleEvent()
	 nsView::HandleEvent()
	 nsView::HandleEvent()
	 nsView::HandleEvent()
	 nsView::HandleEvent()
	 nsViewManager::DispatchEvent()
	 HandleEvent()
	 nsWidget::DispatchEvent()
	 nsWidget::DispatchWindowEvent()
	 nsWidget::OnButtonPressSignal()
	 nsWindow::HandleGDKEvent()
	 dispatch_superwin_event()
	 handle_gdk_event()
	 libgdk-1.2.so.0 + 0x17b7f (0x4034fb7f)
	 libglib-1.2.so.0 + 0x11987 (0x40383987)
	 libglib-1.2.so.0 + 0x12001 (0x40384001)
	 libglib-1.2.so.0 + 0x121cc (0x403841cc)
	 libgtk-1.2.so.0 + 0x93843 (0x40299843)
	 nsAppShell::Run()
	 nsAppShellService::Run()
	 main1()
	 main()
	 libc.so.6 + 0x1bf31 (0x404bff31)     (38034631)	Comments: scrolling in print preview
     (38031994)	URL: www.webseduction.com
(38031994)
Comments: Registring  I was at step #4  clicked on next and BOUM!
     (38030635)	URL: www.mozilla.org
(38030635)
Comments: bug 110193
     (38028855)	URL: http://bugzilla.mozilla.org/
(38028855)
Comments: Viewing a page that had no scroll bars (bugzilla home page) while
pulling the scroll wheel rapidly while mousing off the right edge of the window.
     (38027205)	URL: www.totalise.co.uk
(38027153)
URL: www.totalise.co.uk
(38024882)
URL: www.litestep.net (38024882)	Comments: just after i logged in as a user
     (38019317)	Comments: java applets running
     (38018671)	Comments: Using the mouse in a print preview of slashdot
     (38018640)	Comments: Using mouse wheel in print preview of slashdot
     (38017202)	Comments: Viewing bugzilla query page (prior to makein g query); scrolling
with wheel mouse

Comment 17

[Blake Ross]

Attachment: patch

Comment 18

[Joe Hewitt (gone)]

Comment on attachment 58065 [details] [diff] [review]
patch

sr=hewitt

Comment 19

[Blake Ross]

reassigning to me.

Comment 20

[R.K.Aa.]

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

Comment 21

[Scott Tran (Wildcard)]

Since 110479 is a dupe of this bug and mentions nothing about printing I suggest
we  
up this to BLOCKER status.
Severity->Blocker 

Comment 22

[Blake Ross]

I checked in the fix for this yesterday.

Comment 23

[Mike Pinkerton (not reading bugmail)]

good job, boys. you fixed the crash. too bad you broke the scrollwheel on osx
entirely in the process.

Comment 24

[Mike Pinkerton (not reading bugmail)]

Attachment: make it work again on MacOS X

the diff isn't pretty for some reason, but it just puts things back to the way
they were, not bailing out if we don't find content. makes OSX work again.

Comment 25

[Brian Ryner (not reading)]

Comment on attachment 58147 [details] [diff] [review]
make it work again on MacOS X

r=bryner

Comment 26

[Ashley Bischoff (blog at handcoding.com)]

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

Comment 27

[Matthias Versen [:Matti]]

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

Comment 28

[Mike Pinkerton (not reading bugmail)]

marking this fixed. ignore the last attachment. i have a true fix in bug 112448.

Comment 29

[sujay]

eberry, please verify....and mark verified-fixed...thanks.

Comment 30

[eberry]

This specific crash is fixed, but the mouse wheel events are not captured in
print preview about half of the time (today's .9.8 branch, W2K).  If that still
happens on the nightly builds, I'll file a new bug, though.