JDK-8169341 : Broken JavaScript-to-Java callback in WebEngine with 2nd call
  • Type: Bug
  • Component: javafx
  • Sub-Component: web
  • Affected Version: 8,9
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2016-11-07
  • Updated: 2019-03-23
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.
Other
tbdUnresolved
Related Reports
Relates :  
Relates :  
Relates :  
Description
Problem:
The ability to call back to Java from JavaScript breaks after loading a page
the 2nd time. The callback only survives the 1st page load.

Platform:
The bug applies to both Java 8u112 Mac + Windows

Java Version:
Current Java 9 early edition. It may exist in earlier editions too.

How to reproduce:

1) Create and install a WebView component in a UI
2) Install a Javascript-to-java callback in accordance with
https://docs.oracle.com/javase/8/javafx/api/javafx/scene/web/WebEngine.html

3) Load a page that triggers the javascript-to-java callback
4) Test the page. Should work
5) Now reload the page
6) The callback mechanism is now broken (nothing happens). Trying to
reinstall it in the StateProperty callback doesn��t help either.

Workaround:
Create another WebView+WebEngine instance and set up the callback mechanism
once again. However, this causes other problems: On Mac one sometimes get
complaints about lock files in the file system:

javafx.scene.web.DirectoryLock$DirectoryAlreadyInUseException:
/Users/david/Library/Application Support/Java/webview
at javafx.scene.web.DirectoryLock.<init>(DirectoryLock.java:61)
at javafx.scene.web.WebEngine.applyUserDataDirectory(WebEngine.java:1060)
at javafx.scene.web.WebEngine.load(WebEngine.java:929)
at net.jalbum.browser.WebViewBrowser.lambda$load$7(WebViewBrowser.java:185)
at
com.sun.javafx.application.PlatformImpl.lambda$null$173(PlatformImpl.java:295)
at java.security.AccessController.doPrivileged(Native Method)
at
com.sun.javafx.application.PlatformImpl.lambda$runLater$174(PlatformImpl.java:
294)
at
com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95) 
Comments
I tested in older JDK 8u (like 8GA, 8u76, 8u101, 8u102, 8u112,8u122) by keeping window.setMember("app", new JavaApplication()); outside of webEngine.setOnStatusChanged and reload followed by exit never worked. I attached the file WebEngineError.java where i mentioned the workaround and it works for all the reload/exit cases. I suggest, reporter can try the workaround with the attached file.
16-11-2016

Changing Fix Version to tbd_major as we have a workaround for this issue and priority to P4
15-11-2016

Tested by reverting the fix for JDK-8089681 and still i can see this issue (either by passing localRef OR even by having a ref from java side). As per the JDK-8089681 fix, passing local Java object (new JavaApplication()) will be Gc'ed and in this case callback mechanism does not work.
15-11-2016

1. Click on "exit" without reloading by adding System.gc() Tested below code by adding System.gc() and observed that application does not exit upon clicking on "exit" (Due to the behaviour change as part of the fix for JDK-8089681) and this is expected behaviour. JSObject window = (JSObject) webEngine.executeScript("window"); window.setMember("app", new JavaApplication()); System.gc(); 2. Tested the code by keeping a reference from java side and when i reload the page and click on "exit", app does not exiting. This seems like a different issue and need to check reload case (as this page is local, reload will just load from cache). We can raise a new issue for 2nd point. private final JavaApplication obj = new JavaApplication(); JSObject window = (JSObject) webEngine.executeScript("window"); window.setMember("app", obj);
09-11-2016

Note that it is possible that something else is happening here, so it will need to be tested.
08-11-2016

Assign to Murali to evaluate. I suspect that this might not be a bug, but rather the application's reliance on unspecified behavior, where we used to hold a strong reference on the JavaScript side to any bound Java variable. This was changed in 8u112 to fix a long-standing memory leak. See JDK-8089681.
08-11-2016