User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:2.0b11) Gecko/20100101 Firefox/4.0b11 Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b11) Gecko/20100101 Firefox/4.0b11 Developing plugin which uses standard Windows fileselector causes main browser window stops repainting when plugin-container.exe is used to host the plugin. Other dialogs opened by plugin either messageBox or modal dialog based on resources work fine. The problem does not occure when plugin runs in Firefox process (dom.ipc.plugins.enable: false). Reproducible: Always Steps to Reproduce: 1.Build (or download from attachment) plugin npff4-crsh.dll and register in browser 2.Open test.html (attachment) 3.Click [showFileSelector()] button 4.Move the opened file selector around Actual Results: Browser stops repainting. Only plugin window inside the page gets repainted. Expected Results: Browser window repaints as ussually when the dialogbox is opened. I have prepared a basic plugin based on the npruntime scriptable plugin sample, that demonstrates the problem. It is available for download from following URLs. Prebuilt DLL: http://tinyurl.com/6gtecpz Source code including VS2008 sln/vcproj files: http://tinyurl.com/6bpwv69 Test page: http://tinyurl.com/646fg8y
Component: Extension Compatibility → Plug-ins
Product: Firefox → Core
QA Contact: extension.compatibility → plugins
wfm with Mozilla/5.0 (Windows NT 6.1; rv:2.0b12pre) Gecko/20110214 Firefox/4.0b12pre SeaMonkey/2.1b3pre
Tried in Mozilla/5.0 (Windows NT 5.1; rv:2.0b12pre) Gecko/20110214 Firefox/4.0b12pre Still does not work for me. And more the plugin container crashed when I switched to another window and back to FF. Attached you can find screenshot showing the plugin window gets repainted while rest of browser does not. The crashreport is here: https://crash-stats.mozilla.com/report/index/6a4782ed-8a5b-4ae7-bede-7aaed2110215 And again - when plugin-container.exe is disabled, everything works fine. No crash, no repaint problem.
This is a known limitation on our scripting interface for plugins. Technically not supported but we would like to get a fix for this at some point. This also happens in flash.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: when plugin opens file selector browser stops repainting when plugin-container.exe is used to host plugin → Plugin dialogs invoked through page script cause browser hang [@ hang | NtUserWaitMessage | InternalDialogBox ]
Summary: Plugin dialogs invoked through page script cause browser hang [@ hang | NtUserWaitMessage | InternalDialogBox ] → Modal plugin dialogs invoked through page script cause browser hang [@ hang | NtUserWaitMessage | InternalDialogBox ]
Signature hang | NtUserWaitMessage | InternalDialogBox UUID 6a4782ed-8a5b-4ae7-bede-7aaed2110215 Process Type plugin Version: Filename: npff4-crsh.dll Time 2011-02-15 06:12:19.842436 Uptime 47 Install Age 7592 seconds (2.1 hours) since version was first installed. Product Firefox Version 4.0b12pre Build ID 20110214030347 Branch 2.0 OS Windows NT OS Version 5.1.2600 Service Pack 3 CPU x86 CPU Info GenuineIntel family 6 model 15 stepping 10 Crash Reason EXCEPTION_BREAKPOINT Crash Address 0x7c90e514 User Comments App Notes Cisco VPN AdapterVendorID: 10de, AdapterDeviceID: 042b, AdapterDriverVersion: 184.108.40.20658 Processor Notes EMCheckCompatibility False Bugzilla - Report this Crash Related Bugs Bug 633985 NEW Modal plugin dialogs invoked through page script cause browser hang [@ hang | NtUserWaitMessage | InternalDialogBox ] Bug 618685 NEW Flash plugin hang [@ hang | InternalDialogBox ] | [@ hang | NtUserWaitMessage | InternalDialogBox ] | [@ F840896513__________________________________________________ ] Crashing Thread Frame Module Signature [Expand] Source 0 ntdll.dll KiFastSystemCallRet 1 user32.dll NtUserWaitMessage 2 user32.dll InternalDialogBox 3 user32.dll DialogBoxIndirectParamAorW 4 user32.dll DialogBoxIndirectParamW 5 comdlg32.dll NewGetFileName 6 comdlg32.dll NewGetOpenFileName 7 comdlg32.dll GetFileName 8 comdlg32.dll GetOpenFileNameW 9 npff4-crsh.dll npff4-crsh.dll@0x362f3 10 npff4-crsh.dll npff4-crsh.dll@0x3527c 11 xul.dll mozilla::plugins::PluginScriptableObjectChild::AnswerInvoke dom/plugins/PluginScriptableObjectChild.cpp:710 12 xul.dll mozilla::plugins::PPluginScriptableObjectChild::OnCallReceived obj-firefox/ipc/ipdl/PPluginScriptableObjectChild.cpp:764 13 xul.dll mozilla::plugins::PPluginModuleChild::OnCallReceived obj-firefox/ipc/ipdl/PPluginModuleChild.cpp:574 14 xul.dll mozilla::ipc::RPCChannel::DispatchIncall ipc/glue/RPCChannel.cpp:512 15 xul.dll mozilla::ipc::RPCChannel::Incall ipc/glue/RPCChannel.cpp:498 16 xul.dll mozilla::ipc::RPCChannel::OnMaybeDequeueOne ipc/glue/RPCChannel.cpp:429 17 xul.dll MessageLoop::RunTask ipc/chromium/src/base/message_loop.cc:343 18 xul.dll MessageLoop::DeferOrRunPendingTask ipc/chromium/src/base/message_loop.cc:351 19 xul.dll MessageLoop::DoWork ipc/chromium/src/base/message_loop.cc:451 20 xul.dll base::MessagePumpForUI::DoRunLoop ipc/chromium/src/base/message_pump_win.cc:213 21 xul.dll base::MessagePumpWin::RunWithDispatcher ipc/chromium/src/base/message_pump_win.cc:52 22 xul.dll base::MessagePumpWin::Run ipc/chromium/src/base/message_pump_win.h:78 23 xul.dll MessageLoop::RunInternal ipc/chromium/src/base/message_loop.cc:219 24 xul.dll MessageLoop::RunHandler 25 xul.dll MessageLoop::Run ipc/chromium/src/base/message_loop.cc:176 26 xul.dll XRE_InitChildProcess toolkit/xre/nsEmbedFunctions.cpp:515 27 plugin-container.exe wmain toolkit/xre/nsWindowsWMain.cpp:128 28 plugin-container.exe __tmainCRTStartup obj-firefox/memory/jemalloc/crtsrc/crtexe.c:591 29 kernel32.dll BaseProcessStart We basically ask you not to perform synchronous calls from the ui thread. In the non plugin-container case, you hang the browser and everything in it. In the plugin-container case, we detect that you're doing something rude and shoot you. For Vista and better, you should try switching to: Common Item Dialog http://msdn.microsoft.com/en-us/library/bb776913%28v=vs.85%29.aspx That should enable asynchronous dialogs at least from the windows api layer. If your web page api is sync, then you're more or less in trouble and you should break the api and redesign it.
Of note, the reason we can't simply reenter our event loop in the main case is that our layout engine makes certain assertions which would be violated horribly if we did. It's also part of how the web works, we promise a web page that nothing will "happen" until the script it's running "finishes" - "run to completion". if we allowed gecko to do work while your common dialog was running, this promise would break immediately without significant effort on our part. (It isn't absolutely impossible to prevent this, but it is incredibly expensive, and results in confusion to the user, as they'd be able to try to resize windows, but the contents shouldn't change because of the promise to the related pages.)
In non plugin-container case, the browser doesn't hang when fileselector is opened. Even actions planned by setTimeout are properly triggered.
Crash Signature: [@ hang | NtUserWaitMessage | InternalDialogBox ]
Jim, are you saying in comment #4 that this is a problem we can fix? I don't quite understand if it's a problem on our side or the Adobe side - do we know?
(In reply to comment #8) > Jim, are you saying in comment #4 that this is a problem we can fix? I don't > quite understand if it's a problem on our side or the Adobe side - do we > know? Yes but it would involve some ugly hacks. It would be better to wait for content processes which may fix issues like this by isolating the main ui from plugins.
Resolving old bugs which are likely not relevant any more, since NPAPI plugins are deprecated.
Status: NEW → RESOLVED
Last Resolved: 11 months ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.