633985 - Modal plugin dialogs invoked through page script cause browser hang [@ hang | NtUserWaitMessage | InternalDialogBox ]

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Plug-ins, defect)

Description

[Ludek]

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

Comment 1

[Matthias Versen [:Matti]]

wfm with  Mozilla/5.0 (Windows NT 6.1; rv:2.0b12pre) Gecko/20110214 Firefox/4.0b12pre SeaMonkey/2.1b3pre

Comment 2

[Ludek]

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.

Comment 3

[Ludek]

Attachment: screenshot of unrepainted ff window

Comment 4

[Jim Mathies [:jimm]]

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.

Comment 5

[timeless]

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: 6.14.12.6658
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.

Comment 6

[timeless]

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.)

Comment 7

[Ludek]

In non plugin-container case, the browser doesn't hang when fileselector is opened. Even actions planned by setTimeout are properly triggered.

Comment 8

[Sheila Mooney]

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?

Comment 9

[Jim Mathies [:jimm]]

(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.

Comment 10

[Benjamin Smedberg]

Resolving old bugs which are likely not relevant any more, since NPAPI plugins are deprecated.