JDK-8168625 : Java WebView communication between java and javascript fails in Java 8 U112
  • Type: Bug
  • Component: javafx
  • Sub-Component: web
  • Affected Version: 8u112,9
  • Priority: P2
  • Status: Closed
  • Resolution: Not an Issue
  • OS: windows
  • CPU: x86
  • Submitted: 2016-10-25
  • Updated: 2016-12-17
  • Resolved: 2016-11-03
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9Resolved
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Description
Our javafx application extensively uses communication between java and javascript via
netscape.javascript.JSObject.call and JSObject.setMember().

These functions worked completely fine in Java 8 U92, but when we upgraded to Java 8 U112, we only can use these method for a limited amount of time before they start failing and they no longer get called and don't print out any error.

For example, the attached JavaFxInteropt will run indefinitely in Java 8 U92 (I've gotten the counter up to 11,000 and I stopped counting, but it will fail pretty quickly in Java 8 U112 (when the counter is up to 160 or so, it fails and stops communicating between java and javascript.

The page simulates the bug found in our software, we have a single web view and we have a bunch of interropt calls and users refresh the webview and we expect that calls to continue indefinitely since they are setup fresh on each State.SUCCEEDED when the Web Engine is loaded.

This back and forth between java and javascript is very important to our product and it we cannot run our software without consistent communication between java and javascript.

Comments
Apart from setMember API, Debugged this issue for other JSObject API's like "call" and "setSlot" methods which takes Object as one of the parameters. So "call" and "setSlot" follow the same flow similar to setMember and creates weakRef. Hence, in this case, we need to pass StrongRef to these 2 API's also (apart from setMember) to make Interopt to work. We need to update the document (as part of JDK-8169204) for "call" and "setSlot" API's.
03-11-2016

Closing this issue as "Not an issue" based on above comments.
03-11-2016

Thanks for tracking this down Murali. Your analysis seems good. In the case of the test program the way it uses the arg passed into call(...) is to store a reference from within JavaScript that survives that call (so is subject to GC). And setSlot is basically another variant of setMember, so yes both need to be documented. I think you can close this JBS bug as "Not an issue".
03-11-2016

Kevin, Thanks for the quick response. I made a strong reference for the Java Objects passed into "JSObject.setMember" and GC was still causing my JavaFxInteropt.java to fail (I just added add objects to a static array). To keep the interopt going, it seems that I also have to make my own Strong Reference to the object arguments passed into JSObject.call(String, Object...) or I continue to get a failure when GC is called. Is this expected behavior that is documented as well or can we transition the bug to JSObject.call. The arguments seems like an odd thing to have create Strong References for or is this expected? Since its not just JSObject.setMember, can you provide a full list of parameters that require their own Strong references within that class? Are there any classes within the netscape.javascript packages that also require strong references? Can we update the netscape.javascript.JsObject documentation with those locations?
27-10-2016

In particular, the following code passes a short-lived reference to setMember and is almost certainly the cause of the problem. getWindow().setMember(name, asFunc(webEngine, "get", new SupplierReflectionWrapper<R>(func), name)); Please double-check my speculation, but I suspect that this JBS issue can be closed as "Not an issue".
25-10-2016

This is likely due to the intentional change in behavior to address JDK-8089681 in 8u102, in order to fix a memory leak where WebKit was holding onto Java objects that were bound to JavaScript objects. If so, then this is a bug in the application is that they are relying on the unspecified leak behavior. The fact that we use weak references is now documented; see JDK-8154127.
25-10-2016