1232423 - [FF42] [Windows] Modal dialogs\liveconnect problems when java plugin is running inside plugin-container.exe

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Plug-ins, defect)

Description

[Victor]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/600.3.18 (KHTML, like Gecko) Version/7.1.3 Safari/537.85.12

Steps to reproduce:

Currently java modal dialogs and javaScript-To-Java calls(https://docs.oracle.com/javase/tutorial/deployment/applet/invokingAppletMethodsFromJavaScript.html) don't work properly on Firefox(after FF42 release). It is caused by the following circumstances:

1) When the modal dialog is displayed, we are running our message loop in main browser thread  (using NPN_PluginThreadAsyncCall()), so the dialog is browser modal (user is not able to click on any FF buttons).
2) For FF42, by default our plugin is launched from plugin-container.exe, so we cannot run the message loop in actual browser thread anymore (at least, using NPN_PluginThreadAsyncCall()). Therefore, it seems like we cannot provide browser modality for dialogs.
3) There is another issue: for FF42, when modal dialog is displayed, if we try to change focus from the dialog to main Firefox window(by double-clicking on main FF window title), the dialog becomes unresponsive. The dialog window doesn't receive any messages after the focus change. The browser itself is also unresponsive.
So, it looks like a problem of IPC between firefox.exe<->plugin-container.exe. Also, I'd like to ask, how this mechanism works on browser side. Are there additional restrictions when plugin is running inside plugin-container.exe?


Actually, we've already disabled the browser modality(we don't try to block main plugin thread for all modal dialogs) in next release. But still there is the case when we have to block the main plugin thread: when we perform a JavaScript-to-Java call,  we need to wait a result of the call (NPClass.invoke -> our code blocks the thread, awaiting java method completion). If a modal dialog is displayed during the JavaScript-to-Java call, then we return to problem I described above (dialog may become unresponsive after the focus change). And in this case we cannot avoid main plugin thread blocking.
Another problem is that JavaScript-to-Java calls cannot be running longer than 11 secs (dom.ipc.plugins.hangUITimeoutSecs), otherwise there will be "Plugin unresponsive" dialog from Firefox. It makes our liveconnect support very restricted for latest Firefox. Is there a way to avoid this restriction? 

Steps to demonstrate the problem:
1) Install jre 8u66.
2) Install Firefox 42.
3) Go to http://www.java.com/en/download/installed8.jsp, click on "Verify Java version".
4) Wait when security dialog("Do you want to run this application?") is displayed.   <------ at this point we are running our message loop in main plugin thread  (using NPN_PluginThreadAsyncCall())
5) Try to change the focus from the dialog to main Firefox window(by double-clicking on main FF window title).
6) The security dialog becomes unresponsive, the dialog window doesn't receive input events anymore.



Actual results:

Java dialog becomes unresponsive, the dialog window doesn't receive input events anymore. The main FF window is also unresponsive.


Expected results:

We realise that we cannot provide browser modality when running inside plugin-container.exe, but browser\dialog should not be unresponsive after the focus change. 
(also there are couple of questions in the description)
The problem exists only for Windows.

Comment 1

[jonesr]

I have an application that makes heavy use of LiveConnect, and have been getting reports from windows users since FF42 of failures, sounds like this might be the cause. Reverting to FF41 apparently fixes the issue. Sorry, still collecting details at the moment, so nothing more specific to report yet.

Comment 2

[Loic]

Probably a dupe of bug 1224549.

Comment 3

[Benjamin Smedberg]

Closing old bugs: as of Firefox 52 we no longer support the Java plugin.