466433 - Crash [@ CallQueryInterface<nsIFrame,nsIScrollableViewProvider>] with MozMousePixelScroll event and removing window

Status: VERIFIED FIXED

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Martijn Wargers (dead)]

Attachment: testcase

See testcase.

The iframe src consists of this:
<script>
window.addEventListener('MozMousePixelScroll', function() {window.frameElement.parentNode.removeChild(window.frameElement)}, true);
</script>

http://crash-stats.mozilla.com/report/index/d9b794f0-27a0-4a79-9676-9bac62081124?p=1
0  	xul.dll  	CallQueryInterface<nsIFrame,nsIScrollableViewProvider>  	 obj-firefox/dist/include/xpcom/nsISupportsUtils.h:203
1 	xul.dll 	xul.dll@0x89f867 	
2 	xul.dll 	xul.dll@0x2f2690 	
3 		@0x2e643bf 	
4 		@0x12f4d3

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

My guess is that pixel scrolling must be disabled to reproduce the crash on
Mac. The fix is probably to use nsWeakFrame to check if frame is deleted
while dispatching MozMousePixelScroll event

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

Attachment: proposed patch

This is what we should do IMO.
Other option would be to check mCurrentTarget, but that might change because
of some other reason than deletion.
(BTW, mCurrentTarget is also an nsWeakFrame, so it never points to a deleted frame.)

Comment 3

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 349741 [details] [diff] [review]
proposed patch

a191=beltzner

Comment 4

[Martijn Wargers (dead)]

Verified fixed, using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20081204 Minefield/3.2a1pre

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

Fixed on trunk and 1.9.1

Comment 6

[Aakash Desai [:aakashd]]

verified FIXED on Shiretoko: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090422 Shiretoko/3.5b4pre ID:20090422042031