User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20091215 Minefield/3.7a1pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20091215 Minefield/3.7a1pre With dom.ipc.plugins.enabled set to true, if I pause a Flash video then switch to a different process, Firefox will hang indefinitely until I kill mozilla-runtime.exe. Pausing and unpausing the video without Firefox losing focus is fine, as is switching to another process while the video is playing. Reproducible: Always Steps to Reproduce: 1. Set dom.ipc.plugins.enabled to true. 2. Load up any Flash video on Youtube. 3. Pause it, then switch to another process. 4. Try to interact with the browser. Actual Results: Firefox hangs until mozilla-runtime.exe is forcibly killed (after which Flash, and presumably all plugins, are disabled until the browser is restarted). Expected Results: Firefox continues to work as normal. Tested on Windows 7 x64.

Just to be clear here, what do you mean by switch to another process?

When I tested this I was chatting to someone, and had the messenger window open next to (but not overlapping) Firefox. I paused the video I was watching to focus on the chat, but after switching to the IM client, Firefox would hang (I tested this several times to make sure dom.ipc.plugins.enabled was the cause, but didn't try moving either of the windows about).

I can't reproduce using the same setup. What version of Flash? I'm using: File: NPSWF32.dll Version: 10.0.32.18 Shockwave Flash 10.0 r32

I'm using version 10.0.42.34. Just confirmed it's still happening in today's build and with all Extensions and all other Plugins disabled. I don't specifically have to switch to a different process - simply clicking on the desktop while a video is paused is enough to hang the browser.

Can you give us a link to one of these videos that you can reproduce this with? Might be specific to the encoding or something like that because I have a bug where Firefox is crashing at the end of a video but flash videos elsewhere do not crash. I actually may have reproduced this earlier but I'm trying to reproduce it now to make sure and give STR before I confirm this.

Confirming this using 1216 nightly. STR: 1) Launch Firefox 2) Unmaximize window and resize so you can see a good portion of the desktop 3) Go to http://www.youtube.com/watch?v=3Un0QJHIjhA&feature=popular 4) let video play for about five seconds 5) Click on the desktop a few times in a row...wait about five more seconds 6) Firefox is hung. If not, click play and then Firefox won't respond at all and video won't play. Might have to repeat a second time by just closing the youtube tab and opening it again. No need for a restart.

I was using http://www.youtube.com/watch?v=Eh_gZicYTVg to reproduce. It's very consistent for me - pause, click on desktop, Firefox hangs, every time. Is it the video or a difference in configuration?

Parent stack: kernel32.dll!_WaitForMultipleObjectsExImplementation@20() + 0x8e bytes user32.dll!_RealMsgWaitForMultipleObjectsEx@20() + 0xe2 bytes user32.dll!_MsgWaitForMultipleObjects@20() + 0x1f bytes > xul.dll!mozilla::ipc::SyncChannel::WaitForNotify() Line 504 + 0x13 bytes C++ xul.dll!mozilla::ipc::RPCChannel::Call(IPC::Message * msg=0x063fc420, IPC::Message * reply=0x0038cecc) Line 116 C++ xul.dll!mozilla::plugins::PPluginInstanceParent::CallNPP_HandleEvent(const mozilla::plugins::NPRemoteEvent & event={...}, short * handled=0x0038cf50) Line 362 + 0x16 bytes C++ xul.dll!mozilla::plugins::PluginInstanceParent::NPP_HandleEvent(void * event=0x0038d630) Line 508 + 0x10 bytes C++ xul.dll!mozilla::plugins::PluginModuleParent::NPP_HandleEvent(_NPP * instance=0x071ca6d0, void * event=0x0038d630) Line 293 C++ xul.dll!nsNPAPIPluginInstance::HandleEvent(void * event=0x0038d630, int * handled=0x0038d050) Line 1368 + 0x4e bytes C++ xul.dll!nsPluginInstanceOwner::ProcessEvent(const nsGUIEvent & anEvent={...}) Line 4433 C++ xul.dll!nsObjectFrame::HandleEvent(nsPresContext * aPresContext=0x04fc8f88, nsGUIEvent * anEvent=0x0038d600, nsEventStatus * anEventStatus=0x0038d18c) Line 1914 + 0x16 bytes C++ xul.dll!nsPresShellEventCB::HandleEvent(nsEventChainPostVisitor & aVisitor={...}) Line 1335 C++ xul.dll!nsEventTargetChainItem::HandleEventTargetChain(nsEventChainPostVisitor & aVisitor={...}, unsigned int aFlags=0x00000006, nsDispatchingCallback * aCallback=0x0038d288, int aMayHaveNewListenerManagers=0x00000001, nsCxPusher * aPusher=0x0038d198) Line 367 C++ xul.dll!nsEventDispatcher::Dispatch(nsISupports * aTarget=0x0af878e8, nsPresContext * aPresContext=0x04fc8f88, nsEvent * aEvent=0x0038d600, nsIDOMEvent * aDOMEvent=0x00000000, nsEventStatus * aEventStatus=0x0038d460, nsDispatchingCallback * aCallback=0x0038d288, nsCOMArray<nsPIDOMEventTarget> * aTargets=0x00000000) Line 584 + 0x1e bytes C++ xul.dll!PresShell::HandleEventInternal(nsEvent * aEvent=0x0038d600, nsIView * aView=0x07077fb0, nsEventStatus * aStatus=0x0038d460) Line 6495 + 0x2b bytes C++ xul.dll!PresShell::HandleEvent(nsIView * aView=0x07077fb0, nsGUIEvent * aEvent=0x0038d600, nsEventStatus * aEventStatus=0x0038d460) Line 6253 + 0x1a bytes C++ xul.dll!nsViewManager::HandleEvent(nsView * aView=0x07077fb0, nsPoint aPoint={...}, nsGUIEvent * aEvent=0x0038d600) Line 1202 C++ xul.dll!nsViewManager::DispatchEvent(nsGUIEvent * aEvent=0x0038d600, nsIView * aView=0x07077fb0, nsEventStatus * aStatus=0x0038d5b8) Line 1178 + 0x1e bytes C++ xul.dll!HandleEvent(nsGUIEvent * aEvent=0x0038d600) Line 168 C++ xul.dll!nsWindow::DispatchEvent(nsGUIEvent * event=0x0038d600, nsEventStatus & aStatus=nsEventStatus_eIgnore) Line 3001 + 0xc bytes C++ xul.dll!nsWindow::DispatchWindowEvent(nsGUIEvent * event=0x0038d600) Line 3025 C++ xul.dll!nsWindow::DispatchPluginEvent(const tagMSG & aMsg={...}) Line 3195 + 0x14 bytes C++ xul.dll!nsWindow::ProcessMessageForPlugin(const tagMSG & aMsg={...}, long * aResult=0x0038dc7c, int & aCallDefWndProc=0x00000000) Line 3716 + 0xc bytes C++ xul.dll!nsWindow::ProcessMessage(unsigned int msg=0x00000281, unsigned int & wParam=0x00000001, long & lParam=0xc000000f, long * aRetValue=0x0038dc7c) Line 3739 + 0x17 bytes C++ xul.dll!nsWindow::WindowProc(HWND__ * hWnd=0x00980218, unsigned int msg=0x00000281, unsigned int wParam=0x00000001, long lParam=0xc000000f) Line 3636 + 0x20 bytes C++ user32.dll!_InternalCallWinProc@20() + 0x23 bytes user32.dll!_UserCallWinProcCheckWow@32() + 0xb7 bytes user32.dll!_DispatchClientMessage@24() + 0x51 bytes user32.dll!___fnDWORD@4() + 0x2b bytes ntdll.dll!_KiUserCallbackDispatcher@12() + 0x2e bytes user32.dll!_NtUserMessageCall@28() + 0x15 bytes user32.dll!_SendMessageWorker@24() + 0x59ca bytes user32.dll!_SendMessageW@16() + 0x4c bytes imm32.dll!_ImmSetActiveContext@12() + 0xe2 bytes user32.dll!_FocusSetIMCContext@8() + 0x2c bytes user32.dll!_ImeSystemHandler@16() + 0x4c bytes user32.dll!_ImeWndProcWorker@24() + 0x12f bytes user32.dll!_ImeWndProcW@16() + 0x29 bytes user32.dll!_InternalCallWinProc@20() + 0x23 bytes user32.dll!_UserCallWinProcCheckWow@32() + 0xb7 bytes user32.dll!_DispatchClientMessage@24() + 0x51 bytes user32.dll!___fnDWORD@4() + 0x2b bytes ntdll.dll!_KiUserCallbackDispatcher@12() + 0x2e bytes user32.dll!_NtUserSetFocus@4() + 0x15 bytes xul.dll!nsWindow::SetFocus(int aRaise=0x00000000) Line 1658 C++ xul.dll!nsFocusManager::EnsureCurrentWidgetFocused() Line 985 C++ xul.dll!nsFocusManager::WindowRaised(nsIDOMWindow * aWindow=0x04c33ea8) Line 625 C++ xul.dll!nsWebShellWindow::HandleEvent(nsGUIEvent * aEvent=0x0038e4b4) Line 431 C++ xul.dll!nsWindow::DispatchEvent(nsGUIEvent * event=0x0038e4b4, nsEventStatus & aStatus=nsEventStatus_eIgnore) Line 3001 + 0xc bytes C++ xul.dll!nsWindow::DispatchWindowEvent(nsGUIEvent * event=0x0038e4b4) Line 3025 C++ xul.dll!nsWindow::DispatchFocus(unsigned int aEventType=0x0000006b) Line 3513 + 0x14 bytes C++ xul.dll!nsWindow::DispatchFocusToTopLevelWindow(unsigned int aEventType=0x0000006b) Line 3476 + 0xc bytes C++ xul.dll!nsWindow::ProcessMessage(unsigned int msg=0x00000007, unsigned int & wParam=0x00000000, long & lParam=0x00000000, long * aRetValue=0x0038eb24) Line 4287 + 0xd bytes C++ xul.dll!nsWindow::WindowProc(HWND__ * hWnd=0x00280662, unsigned int msg=0x00000007, unsigned int wParam=0x00000000, long lParam=0x00000000) Line 3636 + 0x20 bytes C++ user32.dll!_InternalCallWinProc@20() + 0x23 bytes user32.dll!_UserCallWinProcCheckWow@32() + 0xb7 bytes user32.dll!_DispatchClientMessage@24() + 0x51 bytes user32.dll!___fnDWORD@4() + 0x2b bytes ntdll.dll!_KiUserCallbackDispatcher@12() + 0x2e bytes user32.dll!_NtUserMessageCall@28() + 0x15 bytes user32.dll!_RealDefWindowProcWorker@24() + 0x6b3e bytes user32.dll!_RealDefWindowProcW@16() + 0x2a bytes user32.dll!_DefWindowProcW@16() + 0x54 bytes user32.dll!_InternalCallWinProc@20() + 0x23 bytes user32.dll!_UserCallWinProcCheckWow@32() + 0xb7 bytes user32.dll!_CallWindowProcAorW@24() + 0x5e bytes user32.dll!_CallWindowProcW@20() + 0x1b bytes xul.dll!nsWindow::WindowProc(HWND__ * hWnd=0x00280662, unsigned int msg=0x00000006, unsigned int wParam=0x00000002, long lParam=0x00000000) Line 3642 + 0x1f bytes C++ user32.dll!_InternalCallWinProc@20() + 0x23 bytes user32.dll!_UserCallWinProcCheckWow@32() + 0xb7 bytes user32.dll!_DispatchClientMessage@24() + 0x51 bytes user32.dll!___fnDWORD@4() + 0x2b bytes ntdll.dll!_KiUserCallbackDispatcher@12() + 0x2e bytes user32.dll!_NtUserPeekMessage@20() + 0x15 bytes user32.dll!__PeekMessage@24() + 0x2d bytes user32.dll!_PeekMessageW@20() + 0x197 bytes xul.dll!PeekKeyAndIMEMessage(tagMSG * msg=0x0038f140, HWND__ * hwnd=0x00000000) Line 78 + 0x18 bytes C++ xul.dll!nsAppShell::ProcessNextNativeEvent(int mayWait=0x00000001) Line 177 + 0xb bytes C++ xul.dll!nsBaseAppShell::DoProcessNextNativeEvent(int mayWait=0x00000001) Line 155 + 0x11 bytes C++ xul.dll!nsBaseAppShell::OnProcessNextEvent(nsIThreadInternal * thr=0x021ef2d8, int mayWait=0x00000001, unsigned int recursionDepth=0x00000000) Line 311 + 0xf bytes C++ xul.dll!nsThread::ProcessNextEvent(int mayWait=0x00000001, int * result=0x0038f204) Line 510 C++ xul.dll!NS_ProcessNextEvent_P(nsIThread * thread=0x021ef2d8, int mayWait=0x00000001) Line 250 + 0x16 bytes C++ xul.dll!mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate * aDelegate=0x021f4d40) Line 142 + 0xe bytes C++ xul.dll!MessageLoop::RunInternal() Line 212 C++ xul.dll!MessageLoop::RunHandler() Line 195 C++ xul.dll!MessageLoop::Run() Line 169 C++ xul.dll!nsBaseAppShell::Run() Line 180 C++ xul.dll!nsAppStartup::Run() Line 182 + 0x1c bytes C++ xul.dll!XRE_main(int argc=0x00000004, char * * argv=0x0048de58, const nsXREAppData * aAppData=0x021e1ff0) Line 3529 + 0x25 bytes C++ Child IOThread stack makes no sense: ntdll.dll!_ZwRemoveIoCompletion@20() + 0x15 bytes ntdll.dll!_ZwRemoveIoCompletion@20() + 0x15 bytes msvcr90d.dll!operator delete(void * pUserData=0x005b9a60) Line 57 + 0x7 bytes C++ > xul.dll!base::MessagePumpWin::GetCurrentDelay() Line 66 + 0xb bytes C++ Child XPCOMThread is dead-stuck in: user32.dll!_NtUserPeekMessage@20() + 0x15 bytes user32.dll!_NtUserPeekMessage@20() + 0x15 bytes xul.dll!nsAppShell::ProcessNextNativeEvent(int mayWait=0x00000001) Line 177 + 0x2a bytes C++ xul.dll!nsBaseAppShell::DoProcessNextNativeEvent(int mayWait=0x00000001) Line 155 + 0x11 bytes C++ xul.dll!nsBaseAppShell::OnProcessNextEvent(nsIThreadInternal * thr=0x005bc358, int mayWait=0x00000001, unsigned int recursionDepth=0x00000000) Line 311 + 0xf bytes C++ xul.dll!nsThread::ProcessNextEvent(int mayWait=0x00000001, int * result=0x02bbf714) Line 510 C++ xul.dll!NS_ProcessNextEvent_P(nsIThread * thread=0x005bc358, int mayWait=0x00000001) Line 250 + 0x16 bytes C++ xul.dll!mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate * aDelegate=0x02bbf8d0) Line 142 + 0xe bytes C++ xul.dll!mozilla::ipc::MessagePumpForChildProcess::Run(base::MessagePump::Delegate * aDelegate=0x02bbf8d0) Line 233 C++ xul.dll!MessageLoop::RunInternal() Line 212 C++ xul.dll!MessageLoop::RunHandler() Line 188 C++ xul.dll!MessageLoop::Run() Line 169 C++ xul.dll!nsBaseAppShell::Run() Line 180 C++ xul.dll!XRE_RunAppShell() Line 442 + 0x19 bytes C++ xul.dll!mozilla::ipc::MessagePumpForChildProcess::Run(base::MessagePump::Delegate * aDelegate=0x02bbf8d0) Line 218 + 0x5 bytes C++ xul.dll!MessageLoop::RunInternal() Line 212 C++ xul.dll!MessageLoop::RunHandler() Line 188 C++ xul.dll!MessageLoop::Run() Line 169 C++ > xul.dll!base::Thread::ThreadMain() Line 168 C++

bent, looks like another manifestation of the deadlock with SendMessage events...

I hit this today on Win7 64bit, and today's nightly build. 1. Open any YouTube video 2. play a few secs and hit pause 3. Opened Notepad and wrote a quick 4 line note, and ctrl+p to print. 4. Closed Notepad 5. Tried to start up the video from step 2, and the browser was not interacting, did not appear to be hung, just not talking to the mouse clicks. Killed mozilla-runtime.exe int the taskmanager, but still did not regain focus of the browser until I switched to another application and back to the browser.

Ah, good point - Windows doesn't produce the '(Not Responding)' message at the end of the title or gray out the window, suggesting that it's not hung in the classic sense.

If it helps, I repro'd this a couple of times using the steps in comment 0, and in a few separate trials got the "Received 'nonqueued' message" error message for message numbers 31 - immediately after the hang 787 - a while after the hang, right-click menu-bar to force-close firefox

This fixes it. I don't understand why yet.

bent, I'm guessing this is r- as the real problem is in SendNativeEvents()? I don't see any reason for NPP_HandleEvent to get called for windowed plugins.

CC'ing some folks from bug 272847 where it appears we began sending IME messages as NPAPI events even in windowed mode. Should we be doing that? Here's an example stack where we end up sending the WM_IME_SETCONTEXT message to windowed flash: xul.dll!mozilla::plugins::PluginInstanceParent::NPP_HandleEvent(void * event=0x0032ba48) Line 566 C++ xul.dll!mozilla::plugins::PluginModuleParent::NPP_HandleEvent(_NPP * instance=0x06fce7e0, void * event=0x0032ba48) Line 301 C++ xul.dll!nsNPAPIPluginInstance::HandleEvent(void * event=0x0032ba48, int * handled=0x0032b458) Line 1378 + 0x4e bytes C++ xul.dll!nsPluginInstanceOwner::ProcessEvent(const nsGUIEvent & anEvent={...}) Line 4429 C++ xul.dll!nsObjectFrame::HandleEvent(nsPresContext * aPresContext=0x067c7130, nsGUIEvent * anEvent=0x0032ba18, nsEventStatus * anEventStatus=0x0032b598) Line 1914 + 0x16 bytes C++ xul.dll!nsPresShellEventCB::HandleEvent(nsEventChainPostVisitor & aVisitor={...}) Line 1337 C++ xul.dll!nsEventTargetChainItem::HandleEventTargetChain(nsEventChainPostVisitor & aVisitor={...}, unsigned int aFlags=6, nsDispatchingCallback * aCallback=0x0032b698, int aMayHaveNewListenerManagers=0, nsCxPusher * aPusher=0x0032b5a4) Line 375 C++ xul.dll!nsEventDispatcher::Dispatch(nsISupports * aTarget=0x06c0bca0, nsPresContext * aPresContext=0x067c7130, nsEvent * aEvent=0x0032ba18, nsIDOMEvent * aDOMEvent=0x00000000, nsEventStatus * aEventStatus=0x0032b878, nsDispatchingCallback * aCallback=0x0032b698, nsCOMArray<nsPIDOMEventTarget> * aTargets=0x00000000) Line 600 + 0x1e bytes C++ xul.dll!PresShell::HandleEventInternal(nsEvent * aEvent=0x0032ba18, nsIView * aView=0x067a82d8, nsEventStatus * aStatus=0x0032b878) Line 6524 + 0x2b bytes C++ xul.dll!PresShell::HandleEvent(nsIView * aView=0x067a82d8, nsGUIEvent * aEvent=0x0032ba18, nsEventStatus * aEventStatus=0x0032b878) Line 6282 + 0x17 bytes C++ xul.dll!nsViewManager::HandleEvent(nsView * aView=0x067a82d8, nsPoint aPoint={...}, nsGUIEvent * aEvent=0x0032ba18) Line 1202 C++ xul.dll!nsViewManager::DispatchEvent(nsGUIEvent * aEvent=0x0032ba18, nsIView * aView=0x067a82d8, nsEventStatus * aStatus=0x0032b9d0) Line 1178 + 0x1e bytes C++ xul.dll!HandleEvent(nsGUIEvent * aEvent=0x0032ba18) Line 168 C++ xul.dll!nsWindow::DispatchEvent(nsGUIEvent * event=0x0032ba18, nsEventStatus & aStatus=nsEventStatus_eIgnore) Line 3015 + 0xc bytes C++ xul.dll!nsWindow::DispatchWindowEvent(nsGUIEvent * event=0x0032ba18) Line 3039 C++ xul.dll!nsWindow::DispatchPluginEvent(const tagMSG & aMsg={...}) Line 3209 + 0x14 bytes C++ xul.dll!nsWindow::ProcessMessageForPlugin(const tagMSG & aMsg={...}, long * aResult=0x0032c094, int & aCallDefWndProc=0) Line 3730 + 0xc bytes C++ xul.dll!nsWindow::ProcessMessage(unsigned int msg=641, unsigned int & wParam=1, long & lParam=-1073741809, long * aRetValue=0x0032c094) Line 3753 + 0x17 bytes C++ xul.dll!nsWindow::WindowProc(HWND__ * hWnd=0x001714e8, unsigned int msg=641, unsigned int wParam=1, long lParam=-1073741809) Line 3650 + 0x20 bytes C++ user32.dll!_InternalCallWinProc@20() + 0x23 bytes user32.dll!_UserCallWinProcCheckWow@32() + 0xb7 bytes user32.dll!_SendMessageWorker@24() + 0x112 bytes user32.dll!_SendMessageW@16() + 0x4c bytes imm32.dll!_ImmSetActiveContext@12() + 0xe2 bytes user32.dll!_FocusSetIMCContext@8() + 0x2c bytes user32.dll!_ImeSystemHandler@16() + 0x4c bytes user32.dll!_ImeWndProcWorker@24() + 0xf3 bytes user32.dll!_ImeWndProcW@16() + 0x29 bytes user32.dll!_InternalCallWinProc@20() + 0x23 bytes user32.dll!_UserCallWinProcCheckWow@32() + 0xb7 bytes user32.dll!_DispatchClientMessage@24() + 0x51 bytes user32.dll!___fnDWORD@4() + 0x2b bytes ntdll.dll!_KiUserCallbackDispatcher@12() + 0x2e bytes user32.dll!_NtUserSetFocus@4() + 0x15 bytes xul.dll!nsWindow::SetFocus(int aRaise=0) Line 1665 C++ xul.dll!nsFocusManager::EnsureCurrentWidgetFocused() Line 985 C++ xul.dll!nsFocusManager::WindowRaised(nsIDOMWindow * aWindow=0x0438cf30) Line 625 C++ xul.dll!nsWebShellWindow::HandleEvent(nsGUIEvent * aEvent=0x0032c800) Line 431 C++ xul.dll!nsWindow::DispatchEvent(nsGUIEvent * event=0x0032c800, nsEventStatus & aStatus=nsEventStatus_eIgnore) Line 3015 + 0xc bytes C++ xul.dll!nsWindow::DispatchWindowEvent(nsGUIEvent * event=0x0032c800) Line 3039 C++ xul.dll!nsWindow::DispatchFocus(unsigned int aEventType=107) Line 3527 + 0x14 bytes C++ xul.dll!nsWindow::DispatchFocusToTopLevelWindow(unsigned int aEventType=107) Line 3490 + 0xc bytes C++ xul.dll!nsWindow::ProcessMessage(unsigned int msg=7, unsigned int & wParam=1250558, long & lParam=0, long * aRetValue=0x0032ce70) Line 4301 + 0xd bytes C++ xul.dll!nsWindow::WindowProc(HWND__ * hWnd=0x000e0276, unsigned int msg=7, unsigned int wParam=1250558, long lParam=0) Line 3650 + 0x20 bytes C++ user32.dll!_InternalCallWinProc@20() + 0x23 bytes user32.dll!_UserCallWinProcCheckWow@32() + 0xb7 bytes user32.dll!_DispatchClientMessage@24() + 0x51 bytes user32.dll!___fnDWORD@4() + 0x2b bytes ntdll.dll!_KiUserCallbackDispatcher@12() + 0x2e bytes user32.dll!_NtUserMessageCall@28() + 0x15 bytes user32.dll!_RealDefWindowProcWorker@24() + 0x69a4 bytes user32.dll!_RealDefWindowProcW@16() + 0x2a bytes user32.dll!_DefWindowProcW@16() + 0x54 bytes user32.dll!_InternalCallWinProc@20() + 0x23 bytes user32.dll!_UserCallWinProcCheckWow@32() + 0xb7 bytes user32.dll!_CallWindowProcAorW@24() + 0x5e bytes user32.dll!_CallWindowProcW@20() + 0x1b bytes xul.dll!nsWindow::WindowProc(HWND__ * hWnd=0x000e0276, unsigned int msg=6, unsigned int wParam=1, long lParam=0) Line 3656 + 0x1f bytes C++ user32.dll!_InternalCallWinProc@20() + 0x23 bytes user32.dll!_UserCallWinProcCheckWow@32() + 0xb7 bytes user32.dll!_CallWindowProcAorW@24() + 0x5e bytes user32.dll!_CallWindowProcW@20() + 0x1b bytes xul.dll!mozilla::ipc::windows::DeferredSendMessage::Run() Line 606 C++ xul.dll!`anonymous namespace'::DeferredMessageHook(int nCode=0, unsigned int wParam=1, long lParam=3331168) Line 153 C++ user32.dll!_DispatchHookW@16() + 0x38 bytes user32.dll!_CallHookWithSEH@16() + 0x21 bytes user32.dll!___fnHkINLPMSG@4() + 0x4f bytes ntdll.dll!_KiUserCallbackDispatcher@12() + 0x2e bytes user32.dll!_NtUserPeekMessage@20() + 0x15 bytes user32.dll!__PeekMessage@24() + 0x2d bytes user32.dll!_PeekMessageW@20() + 0x197 bytes xul.dll!nsAppShell::ProcessNextNativeEvent(int mayWait=0) Line 270 + 0x40 bytes C++ xul.dll!nsBaseAppShell::DoProcessNextNativeEvent(int mayWait=0) Line 155 + 0x11 bytes C++ xul.dll!nsBaseAppShell::OnProcessNextEvent(nsIThreadInternal * thr=0x00aa4998, int mayWait=0, unsigned int recursionDepth=0) Line 293 + 0xd bytes C++ xul.dll!nsThread::ProcessNextEvent(int mayWait=0, int * result=0x0032d5b8) Line 510 C++ xul.dll!NS_ProcessNextEvent_P(nsIThread * thread=0x00aa4998, int mayWait=0) Line 250 + 0x16 bytes C++ xul.dll!mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate * aDelegate=0x00aa2468) Line 118 + 0xe bytes C++ xul.dll!MessageLoop::RunInternal() Line 212 C++ xul.dll!MessageLoop::RunHandler() Line 195 C++ xul.dll!MessageLoop::Run() Line 169 C++ xul.dll!nsBaseAppShell::Run() Line 180 C++ xul.dll!nsAppShell::Run() Line 240 C++ xul.dll!nsAppStartup::Run() Line 182 + 0x1c bytes C++ xul.dll!XRE_main(int argc=4, char * * argv=0x0077c9f8, const nsXREAppData * aAppData=0x0077cf80) Line 3476 + 0x25 bytes C++ firefox.exe!NS_internal_main(int argc=4, char * * argv=0x0077c9f8) Line 158 + 0x12 bytes C++ firefox.exe!wmain(int argc=4, wchar_t * * argv=0x00779ec0) Line 120 + 0xd bytes C++ firefox.exe!__tmainCRTStartup() Line 583 + 0x19 bytes C firefox.exe!wmainCRTStartup() Line 403 C kernel32.dll!@BaseThreadInitThunk@12() + 0x12 bytes ntdll.dll!___RtlUserThreadStart@8() + 0x27 bytes ntdll.dll!__RtlUserThreadStart@8() + 0x1b bytes

Well, if we want to block these events at a higher level then here is a simple fix for that... It avoids the hang but I still have no idea why.

Comment on attachment 420641 [details] [diff] [review] Another workaround Er, ignore the nsLineLayout changes. Totally unrelated.

Comment on attachment 420612 [details] [diff] [review] Fix? Workaround? Lucky guess? I'm not happy with this workaround and prefer the second which fixes this where this behavior was introduced per discussion with bent. Perhaps Masayuki can review the new patch and also verify that it doesn't regress the fix for bug 272847.

(In reply to comment #15) > CC'ing some folks from bug 272847 where it appears we began sending IME > messages as NPAPI events even in windowed mode. Should we be doing that? No, bug 272847 was intended to send NPAPI events only to windowless plug-ins. Windowed plug-ins will receive messages from the operating system directly.

BTW, why do we still send NPAPI events only to Flash Player? Per bug 272847 comment #76, it's supposed to be a temporary solution. For example, windowless Silverlight may want IME messages.

Likely because no one ever filed a followup bug to implement it for all windowless plugins?

Yes, I've never worked for it.

Comment on attachment 420641 [details] [diff] [review] Another workaround Masayuki: this bug is urgent for OOPP, is this "second workaround" patch correct/acceptable (ignoring the nsLineLayout changes)?

Even if we applied the workaround to the trunk, the windowless flash player still could be hanging up, right? Is it ok for now? Do you want just to fix this bug only for windowed mode, temporary?

I don't think we know as of yet whether or not this bug happens in windowless mode. Do you have a link for a windowless mode flash that bent can test? If the bug doesn't exist in windowless mode then I think the second workaround patch as is would be the final patch for this bug. Can you confirm comment #19 and that the second workaround patch meets the requirements from bug 272847 and won't regress it.

http://bugzilla-attachments.mozilla.gr.jp/attachment.cgi?id=2974 The editor of center is windowed mode, the others are windowless mode. I can reproduce the hanging up in the testcase. Set focus to the windowless editor and switch the window from another. Then, the it's frozen. And I think the patch shouldn't be final. nsWindow doesn't need to dispatch the plug-in events when windowed mode plug-in has focus.

Thanks! From the little I know of this code that makes sense though I think with the short schedule for OOPP that the nsWindow work should be done in a followup bug (is there already a bug on file for this?) since that appears to be a pre-existing bug and the second workaround patch just implements what was intended in bug 272847.

Filed bug 538927 for bug 272847 comment #76.

Fort windowed controls, we have a similar hang with the print dialog in flash. When the user selects print, the dialog is displayed and is interactive. When it's closed firefox tries to send an ime-set-context event with flash's main thread still wrapped up in the modal print dialog loop. Dumping handle event calls in the parent when in windowed mode fixes the problem.

Filed bug 539294 on comment 26.

Comment on attachment 420641 [details] [diff] [review] Another workaround http://bugzilla-attachments.mozilla.gr.jp/attachment.cgi?id=2974 Click the right most editor. After that, click the center editor, then even if I applied this patch, Fx has frozen sometimes. And I cannot look the caret in the windowless editors. And also, the composition string is displayed as different on windowless mode. I think this means the flash player couldn't process WM_IME_SETCONTEXT correctly.

We have two problems here: 1) hang in windowed mode 2) hang in windowless mode The first hang is much more serious and urgent to fix. Can we take the smallest fix for that case while we diagnose and fix the problem for the windowless case?

Comment on attachment 420641 [details] [diff] [review] Another workaround O.K. I cannot reproduce the hang only with windowed mode. And IME can use on windowed mode basically. r=masayuki, but please file a new bug for windowless mode before landing.

We definitely should not be sending these in windowed mode, especially not to the windowless event handler. Since flash has a sub class on the window, it's already processed windowing events it wants including these ime events. Pumping a few select ime events through NPP_HandleEvent afte flash has already received them, well, that can't be good! (In reply to comment #31) > > And I cannot look the caret in the windowless editors. Bug 539330?

(In reply to comment #26) > And I think the patch shouldn't be final. nsWindow doesn't need to dispatch the > plug-in events when windowed mode plug-in has focus. nsWindow really doesn't know much about the content in it's windows. Every event it sends has a plugin event piggybacking on top of regular events. The decision on whether to send events to a particular plugin is made farther up in the call stack. (In reply to comment #30) > Filed bug 539294 on comment 26. This should be resolved as won't (can't) fix.

(In reply to comment #35) > This should be resolved as won't (can't) fix. What? We're going to live with plugins crashing every time we switch focus?

Comment on attachment 420641 [details] [diff] [review] Another workaround r+sr=jst with the nsLineLayout changes left out.

(In reply to comment #35) > (In reply to comment #26) > > And I think the patch shouldn't be final. nsWindow doesn't need to dispatch the > > plug-in events when windowed mode plug-in has focus. > > nsWindow really doesn't know much about the content in it's windows. Every > event it sends has a plugin event piggybacking on top of regular events. The > decision on whether to send events to a particular plugin is made farther up in > the call stack. > > (In reply to comment #30) > > Filed bug 539294 on comment 26. > > This should be resolved as won't (can't) fix. I think we should check NS_PLUGIN_WINDOW_PROPERTY_ASSOCIATION. And we should do nothing in our window proc like non-IPC mode, perhaps.

Pushed changeset 276e30f679fc to mozilla-central.

Would you file a bug for windowless mode? And block it the OOPP release by it? I'm guessing that the cause is that the "GeckoPluginWindow" window doesn't have focus. IME instances are created for each process. So, if we send native IME events to another process, plug-ins cannot access to our IME. So, the IME state is different with ours. Perhaps, we need to create a new mechanism for windowless IME handling, plug-ins should be able to access our process's IME via some new APIs.

Could you file that bug? There's bug 540094 already, but the general issue is something that I don't think any of our core team understands well. Why is IME per-process anyway, instead of per-toplevel-window or something sane? Does it have to be that way, or is that just the default behavior?

> Why is IME per-process anyway It's Win32's specification. ::ImmGetContext(HWND) API returns NULL when the HWND param is another process's window handle. So, we cannot access any other process's IME context. I discussed with Makoto san in MJ office. We can take some ways: 1. Create new APIs for plug-ins, they can access to our IME context. 2. Create a dummy (hidden) window on the plug-in process if it's windowless mode. And we set focus to it when the focus moves to plug-in. I think the first is better way, it's not hacky but of course, plug-ins need to update for us. But we should wait the fix of bug 540094, first.

I think jimm is already working on option #2 for unrelated reasons (the hangs when windows shows "Print" dialogs), see bug 538918. In any case, let's make sure a bug is on file.

Blanket approval for Lorentz merge to mozilla-1.9.2 a=beltzner for 1.9.2.4 - please make sure to mark status1.9.2:.4-fixed

Merged into 1.9.2 at http://hg.mozilla.org/releases/mozilla-1.9.2/rev/84ba4d805430

Was this crash limited to 64-bit Windows 7 with Flash 10?

https://litmus.mozilla.org/show_test.cgi?id=11866 added.