404811 - ASSERTION: Mouse move must have some target content with removed documentElement and mousethrough

Status: RESOLVED WORKSFORME

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

Description

[Martijn Wargers (dead)]

Attachment: testcase

See testcase, I get this assertion in current debug trunk build while hovering over the document:
###!!! ASSERTION: Mouse move must have some target content: 'targetElement', fil
e c:/mozilla-build/mozilla/content/events/src/nsEventStateManager.cpp, line 3096

Stack from assertion:
 	ntdll.dll!_DbgBreakPoint@0() 	
>	xpcom_core.dll!Break(const char * aMsg=0x0012e6cc)  Line 480	C++
 	xpcom_core.dll!NS_DebugBreak_P(unsigned int aSeverity=1, const char * aStr=0x0283449c, const char * aExpr=0x0283448c, const char * aFile=0x02834448, int aLine=3096)  Line 358 + 0xc bytes	C++
 	gklayout.dll!nsEventStateManager::GenerateMouseEnterExit(nsGUIEvent * aEvent=0x0012f2e0)  Line 3096 + 0x28 bytes	C++
 	gklayout.dll!nsEventStateManager::PreHandleEvent(nsPresContext * aPresContext=0x04cbf998, nsEvent * aEvent=0x0012f2e0, nsIFrame * aTargetFrame=0x05fc5fb4, nsEventStatus * aStatus=0x0012f084, nsIView * aView=0x02db1638)  Line 895	C++
 	gklayout.dll!PresShell::HandleEventInternal(nsEvent * aEvent=0x0012f2e0, nsIView * aView=0x02db1638, nsEventStatus * aStatus=0x0012f084)  Line 5782 + 0x36 bytes	C++
 	gklayout.dll!PresShell::HandlePositionedEvent(nsIView * aView=0x02db1638, nsIFrame * aTargetFrame=0x05fc5fb4, nsGUIEvent * aEvent=0x0012f2e0, nsEventStatus * aEventStatus=0x0012f084)  Line 5681 + 0x14 bytes	C++
 	gklayout.dll!PresShell::HandleEvent(nsIView * aView=0x02db1638, nsGUIEvent * aEvent=0x0012f2e0, nsEventStatus * aEventStatus=0x0012f084)  Line 5524 + 0x1e bytes	C++
 	gklayout.dll!nsViewManager::HandleEvent(nsView * aView=0x02db1638, nsPoint aPoint={...}, nsGUIEvent * aEvent=0x0012f2e0, int aCaptured=0)  Line 1299	C++
 	gklayout.dll!nsViewManager::DispatchEvent(nsGUIEvent * aEvent=0x0012f2e0, nsEventStatus * aStatus=0x0012f1c4)  Line 1252 + 0x22 bytes	C++
 	gklayout.dll!HandleEvent(nsGUIEvent * aEvent=0x0012f2e0)  Line 171	C++
 	gkwidget.dll!nsWindow::DispatchEvent(nsGUIEvent * event=0x0012f2e0, nsEventStatus & aStatus=nsEventStatus_eIgnore)  Line 1054 + 0xc bytes	C++
 	gkwidget.dll!nsWindow::DispatchWindowEvent(nsGUIEvent * event=0x0012f2e0)  Line 1075	C++
 	gkwidget.dll!nsWindow::DispatchMouseEvent(unsigned int aEventType=300, unsigned int wParam=0, long lParam=44172268, int aIsContextMenuKey=0, short aButton=0)  Line 5961 + 0x1a bytes	C++
 	gkwidget.dll!ChildWindow::DispatchMouseEvent(unsigned int aEventType=300, unsigned int wParam=0, long lParam=44172268, int aIsContextMenuKey=0, short aButton=0)  Line 6143	C++
 	gkwidget.dll!nsWindow::ProcessMessage(unsigned int msg=512, unsigned int wParam=0, long lParam=44172268, long * aRetValue=0x0012f790)  Line 4380 + 0x24 bytes	C++
 	gkwidget.dll!nsWindow::WindowProc(HWND__ * hWnd=0x03e0075c, unsigned int msg=512, unsigned int wParam=0, long lParam=44172268)  Line 1267 + 0x1d bytes	C++
 	user32.dll!_InternalCallWinProc@20()  + 0x28 bytes	
 	user32.dll!_UserCallWinProcCheckWow@32()  + 0xb7 bytes	
 	user32.dll!_DispatchMessageWorker@8()  + 0xdc bytes	
 	user32.dll!_DispatchMessageW@4()  + 0xf bytes	
 	gkwidget.dll!nsAppShell::ProcessNextNativeEvent(int mayWait=1)  Line 149	C++
 	gkwidget.dll!nsBaseAppShell::DoProcessNextNativeEvent(int mayWait=1)  Line 137 + 0x11 bytes	C++
 	gkwidget.dll!nsBaseAppShell::OnProcessNextEvent(nsIThreadInternal * thr=0x00e2be70, int mayWait=1, unsigned int recursionDepth=0)  Line 247 + 0xf bytes	C++
 	xpcom_core.dll!nsThread::ProcessNextEvent(int mayWait=1, int * result=0x0012f984)  Line 480	C++
 	xpcom_core.dll!NS_ProcessNextEvent_P(nsIThread * thread=0x00e2be70, int mayWait=1)  Line 227 + 0x16 bytes	C++
 	gkwidget.dll!nsBaseAppShell::Run()  Line 154 + 0xc bytes	C++
 	tkitcmps.dll!nsAppStartup::Run()  Line 170 + 0x1c bytes	C++
 	xul.dll!XRE_main(int argc=1, char * * argv=0x00e28940, const nsXREAppData * aAppData=0x00e28d20)  Line 3142 + 0x25 bytes	C++
 	firefox.exe!main(int argc=1, char * * argv=0x00e28940)  Line 153 + 0x12 bytes	C++
 	firefox.exe!__tmainCRTStartup()  Line 586 + 0x19 bytes	C
 	firefox.exe!mainCRTStartup()  Line 403	C
 	kernel32.dll!_BaseProcessStart@4()  + 0x23 bytes

Comment 1

[Martijn Wargers (dead)]

Ugh, for some reason, I don't see this assertion anymore, but the testcase is somehow not rendering at all, e.g. the previous document stays visible.
I'm also seeing this with branch builds.

Comment 2

[Martijn Wargers (dead)]

Attachment: cycle collection assertions

So I saw these assertions sometimes appearing with a similar testcase (while opening the context menu?).

I don't get the original assertion in the bug anymore, nor do I seem to get the cycle collection assertions anymore.

And now in trunk, the testcase even renders on trunk (but not on branch, so I guess this needs to stay security sensitive for now).

I'm sorry, this bug is getting a mess :(

Comment 3

[Martijn Wargers (dead)]

Attachment: testcase, where I got the cycle collections assertions with (I think)

Comment 4

[Martijn Wargers (dead)]

(In reply to comment #2)
> And now in trunk, the testcase even renders on trunk (but not on branch, so I
> guess this needs to stay security sensitive for now).

Never mind, I had js turned off.
And it turns out I see the original assertion (of what this bug was supposed to be about) on trunk again with the second testcase, too.

Comment 5

[Jesse Ruderman]

This testcase gets Firefox into a weird state, and there might be spoofing potential.  (For example, you can make it look like your site contains information only your bank would know.  Or, if you can get Gmail to serve the testcase as an attachment, you can make it look like something else is coming from Gmail.)

Comment 6

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

Can't see any CC problems, but otherwise reproduce-able on linux.
mousemove handling doesn't take account the case when document doesn't have
any elements. Not sure if that causes the weird state FF gets into with the first testcase.

Comment 7

[Martijn Wargers (dead)]

I'm still seeing the previous document in current trunk build with the testcase.

Comment 8

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

yes, that is what I meant with the "weird state".

Comment 9

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

Is there any reason to support mousethrough on <window> ?

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

No. Well, it might make sense in theory but we can't actually support it on any platform I know of.

Comment 11

[Daniel Veditz [:dveditz]]

What is the security risk here? This bug seems to be going nowhere, does it really need to remain hidden?

Comment 12

[Jesse Ruderman]

WFM on trunk.  No assertions, no weird painting.