541401 - ASSERTION: cannot call GetUsedPadding on a dirty frame not currently being reflowed with plugins (OOPP?)

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[Benjamin Smedberg]

Get a lot of this assertion with plugins... I don't think it's OOPP specific, but it's making it hard to debug OOPP effectively.

###!!! ASSERTION: cannot call GetUsedPadding on a dirty frame not currently being reflowed: 'nsLayoutUtils::sDisableGetUsedXAssertions || !NS_SUBTREE_DIRTY(this) || (GetStateBits() & NS_FRAME_IN_REFLOW)', file c:/builds/electrolysis/ff-debug/layout/generic/../../../src/layout/generic/nsFrame.cpp, line 619

>	nsIFrame::GetUsedPadding() Line 619	C++
 	nsIFrame::GetUsedBorderAndPadding() Line 838	C++
 	nsPluginInstanceOwner::InvalidateRect(invalidRect=0x003cbbbc) Line 2749	C++
 	nsNPAPIPluginInstance::InvalidateRect(invalidRect=0x003cbbbc) Line 1817	C++
 	mozilla::plugins::parent::_invalidaterect(npp=0x09ec59f8, invalidRect=0x003cbbbc) Line 1318	C++
 	mozilla::plugins::PluginInstanceParent::RecvNPN_InvalidateRect(rect={...}) Line 340	C++
 	mozilla::plugins::PPluginInstanceParent::OnMessageReceived(msg={...}) Line 625	C++
 	mozilla::plugins::PPluginModuleParent::OnMessageReceived(msg={...}) Line 212	C++
 	mozilla::ipc::AsyncChannel::OnDispatchMessage(msg={...}) Line 209	C++
 	mozilla::ipc::RPCChannel::Call(msg=0x0aa149b8, reply=0x003cbd08) Line 129	C++
 	mozilla::plugins::PPluginInstanceParent::CallNPP_HandleEvent(event={...}, handled=0x003cbd84) Line 394	C++
 	mozilla::plugins::PluginInstanceParent::NPP_HandleEvent(event=0x003cbe9c) Line 532	C++
 	mozilla::plugins::PluginModuleParent::NPP_HandleEvent(instance=0x09ec59f8, event=0x003cbe9c) Line 297	C++
 	nsNPAPIPluginInstance::HandleEvent(event=0x003cbe9c, handled=0x003cbe74) Line 1378	C++
 	nsPluginInstanceOwner::ProcessEvent(anEvent={...}) Line 4438	C++
 	nsPluginInstanceOwner::DispatchFocusToPlugin(aFocusEvent=0x06d990f8) Line 3644	C++
 	nsPluginInstanceOwner::Focus(aFocusEvent=0x06d990f8) Line 3620	C++
 	DispatchToInterface(aEvent=0x06d990f8, aListener=0x0a224c58, aMethod=0x6588f8e0, aIID={...}) Line 171	C++
 	nsEventListenerManager::HandleEvent(aPresContext=0x0ad472c0, aEvent=0x003cc15c, aDOMEvent=0x003cc098, aCurrentTarget=0x06dbb128, aFlags=0x00000006, aEventStatus=0x003cc09c, aPusher=0x003cc0a8) Line 1168	C++
 	nsEventTargetChainItem::HandleEvent(aVisitor={...}, aFlags=0x00000006, aMayHaveNewListenerManagers=0x00000000, aPusher=0x003cc0a8) Line 201	C++
 	nsEventTargetChainItem::HandleEventTargetChain(aVisitor={...}, aFlags=0x00000006, aCallback=0x00000000, aMayHaveNewListenerManagers=0x00000000, aPusher=0x003cc0a8) Line 327	C++
 	nsEventDispatcher::Dispatch(aTarget=0x06dbb128, aPresContext=0x0ad472c0, aEvent=0x003cc15c, aDOMEvent=0x00000000, aEventStatus=0x00000000, aCallback=0x00000000, aTargets=0x00000000) Line 600	C++
 	FocusBlurEvent::Run() Line 1668	C++
 	nsContentUtils::AddScriptRunner(aRunnable=0x09fcbe58) Line 4558	C++
 	nsFocusManager::SendFocusOrBlurEvent(aType=0x00000514, aPresShell=0x06f68b98, aDocument=0x06af87b8, aTarget=0x06dbb128, aFocusMethod=0x00000000, aWindowRaised=0x00000000) Line 1715	C++
 	nsFocusManager::Focus(aWindow=0x0ae2be18, aContent=0x06dbb128, aFlags=0x00000000, aIsNewDocument=0x00000001, aFocusChanged=0x00000001, aWindowRaised=0x00000000) Line 1629	C++
 	nsFocusManager::SetFocusInner(aNewContent=0x06dbb128, aFlags=0x00000000, aFocusChanged=0x00000001) Line 1128	C++
 	nsFocusManager::SetFocus(aElement=0x06dbb1c0, aFlags=0x00000000) Line 415	C++
 	nsPluginInstanceOwner::MouseDown(aMouseEvent=0x068233f0) Line 3797	C++
 	DispatchToInterface(aEvent=0x068233f0, aListener=0x0a224c58, aMethod=0x6588f8e0, aIID={...}) Line 171	C++
 	nsEventListenerManager::HandleEvent(aPresContext=0x0ad472c0, aEvent=0x003cca68, aDOMEvent=0x003cc558, aCurrentTarget=0x06dbb128, aFlags=0x00000006, aEventStatus=0x003cc55c, aPusher=0x003cc568) Line 1168	C++

There are a bunch of similar stacks involving nsObjectFrame that don't involve the calls in and out of plugin code.

Comment 1

[Boris Zbarsky [:bzbarsky]]

This particular stack is showing what looks like a "correct" case for the assertion to fire, in that you could be invalidating the wrong area entirely here.

nsPluginInstanceOwner::InvalidateRect should presumably be flushing layout first?  roc, does that make sense?

I'd love to see the other stacks.

Comment 2

[Benjamin Smedberg]

No plugin at all in this one:

 	NS_DebugBreak_P(aSeverity=0x00000001, aStr=0x69c80fa8, aExpr=0x69c80f38, aFile=0x69c80ee0, aLine=0x0000026b) Line 360	C++
 	nsIFrame::GetUsedPadding() Line 619	C++
 	nsIFrame::GetUsedBorderAndPadding() Line 838	C++
 	nsPluginInstanceOwner::ProcessEvent(anEvent={...}) Line 4400	C++
 	nsPluginInstanceOwner::MouseDown(aMouseEvent=0x0c023088) Line 3800	C++
 	DispatchToInterface(aEvent=0x0c023088, aListener=0x07264f08, aMethod=0x686505a0, aIID={...}) Line 171	C++
 	nsEventListenerManager::HandleEvent(aPresContext=0x04aeaef0, aEvent=0x0028c720, aDOMEvent=0x0028c210, aCurrentTarget=0x0a789a00, aFlags=0x00000006, aEventStatus=0x0028c214, aPusher=0x0028c220) Line 1168	C++
 	nsEventTargetChainItem::HandleEvent(aVisitor={...}, aFlags=0x00000006, aMayHaveNewListenerManagers=0x00000000, aPusher=0x0028c220) Line 201	C++
 	nsEventTargetChainItem::HandleEventTargetChain(aVisitor={...}, aFlags=0x00000006, aCallback=0x0028c314, aMayHaveNewListenerManagers=0x00000000, aPusher=0x0028c220) Line 327	C++
 	nsEventDispatcher::Dispatch(aTarget=0x0a789a00, aPresContext=0x04aeaef0, aEvent=0x0028c720, aDOMEvent=0x00000000, aEventStatus=0x0028c528, aCallback=0x0028c314, aTargets=0x00000000) Line 600	C++
 	PresShell::HandleEventInternal(aEvent=0x0028c720, aView=0x09d5d170, aStatus=0x0028c528) Line 6531	C++
 	PresShell::HandlePositionedEvent(aView=0x09d5d170, aTargetFrame=0x06f87a48, aEvent=0x0028c720, aEventStatus=0x0028c528) Line 6377	C++
 	PresShell::HandleEvent(aView=0x09d70470, aEvent=0x0028c720, aEventStatus=0x0028c528) Line 6234	C++
 	nsViewManager::HandleEvent(aView=0x09d70470, aPoint={...}, aEvent=0x0028c720) Line 1146	C++
 	nsViewManager::DispatchEvent(aEvent=0x0028c720, aView=0x09d70470, aStatus=0x0028c680) Line 1122	C++
 	HandleEvent(aEvent=0x0028c720) Line 161	C++
 	nsWindow::DispatchEvent(event=0x0028c720, aStatus=nsEventStatus_eIgnore) Line 3015	C++
 	nsWindow::DispatchWindowEvent(event=0x0028c720) Line 3039	C++
 	nsWindow::DispatchMouseEvent(aEventType=0x0000012e, wParam=0x00000001, lParam=0x029f00a9, aIsContextMenuKey=0x00000000, aButton=0x0000) Line 3422	C++
 	ChildWindow::DispatchMouseEvent(aEventType=0x0000012e, wParam=0x00000001, lParam=0x029f00a9, aIsContextMenuKey=0x00000000, aButton=0x0000) Line 7138	C++
 	nsWindow::ProcessMessage(msg=0x00000201, wParam=0x00000001, lParam=0x029f00a9, aRetValue=0x0028ce08) Line 4048	C++
 	nsWindow::WindowProc(hWnd=0x002c0538, msg=0x00000201, wParam=0x00000001, lParam=0x029f00a9) Line 3653	C++

Comment 3

[Boris Zbarsky [:bzbarsky]]

Hmm.  That one is tough.  We really do want the "old" value there....

Comment 4

[Boris Zbarsky [:bzbarsky]]

It would be easy enough to suppress the asserts, btw; the question is whether they're pointing out incorrect behavior here.

Comment 5

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

I think we should get rid of the assertions by having GetUsed* return correct results in all situations. See
https://bugzilla.mozilla.org/show_bug.cgi?id=539356#c11

Comment 6

[:Cykesiopka]

Bug 542361 removed the assertion.