JavaFX WebView Debugger
Via WebSocket connection to Google Chrome Dev Tools
JavaFx WebView debugging with Chrome Dev tools is highly dependent on Google Chrome version and JavaFx Version.
If you can debug your scripts using another environment, I would highly recommend doing that instead. Only use JavaFx WebView based debugging when you absolutely need to debug the code under this environment.
JavaFx I use for debugging is JetBrains OpenJDK 1.8.0u152 build 1136 which I found to be the most stable for JavaFx WebView debugging. Other versions are more quirky and after starting debug server they need a page reload from the context menu before connecting Chrome Dev Tools. Otherwise, JavaFX crashes and takes the application with it.
I use Chrome version 65.0.3325.181 under OS X. Later versions work but console has no output. I have not investigated what is causing this. You can download older Chrome versions from Google Chrome Older Versions Download (Windows, Linux & Mac)
Here is a teaser screenshot of dev tools running with JavaFX WebView, showing off the console logging from scripts, with caller location for one click navigation to source:
- Java 8 (not tested with 9)
- The project is on Maven:
Take a look at the Web View Debug Sample application for a working example. You can play with it and debug the embedded scripts before deciding whether you want to instrument your own application for Chrome Dev Tools debugging.
<dependency> <groupId>com.vladsch.javafx-webview-debugger</groupId> <artifactId>javafx-webview-debugger</artifactId> <version>0.6.4</version> </dependency>
Credit where credit is due
I found out about the possibility of having any debugger for JavaFX WebView in mohamnag/javafx_webview_debugger. That implementation in turn was based on the solution found by Bosko Popovic.
I am grateful to Bosko Popovic for discovering the availability and to Mohammad Naghavi creating an implementation of the solution. Without their original effort this solution would not be possible.
Finally real debugging for JavaFX WebView
A proxy to get between Chrome Dev Tools and WebView solved most of the WebView debugging protocol limitations. It also allowed to prevent conditions that caused WebView to crash and bring the rest of the application with it. I don't mean a Java exception. I mean a core dump and sudden exit of the application. For my use cases this is not an acceptable option.
If you are working with JavaFX WebView scripts you need this functionality ASAP. Bugs that took hours to figure out now take literally seconds to minutes without any recompilation or major log reading. Take a look at the Web View Debug Sample application to see what you get and how to add it to your code.
What is working
warn. With added extras to output to the Java console:
- all commandLineAPI functions implemented by JavaFX WebView:
- Some limitations do exist because
Runtime.evaluateis simulated. Otherwise, there was no way to get the stack frame for any console log calls that would result from the evaluation. Mainly, it caused the application to exit with a core dump more often than not. I figured it was more important to have the caller location for console logs than for the commandLineAPI calls.
- Some limitations do exist because
- No longer necessary to instrument the page to have
JSBridgesupport code working. Only requires a page reload from WebView or Dev Tools.
- Ability to debug break on page reload to debug scripts running before JSBridge is established
- Safely stop debug session from Dev Tools or WebView side. This should have been easy but turned out to be the hardest part to solve. Any wrong moves or dangling references would bring down the whole application with a core-dump message.
- highlighting of elements hovered over in the element tree of dev tools. Node resolution is working. Kludged highlighting by setting a class on the element with translucent background color defined instead of using an overlay element or the proper margin, borders, padding and container size.
- Debugger paused overlay
Probably not doable
- profiling not available. Don't know enough about what's needed to say whether it is doable.
JSBridge Provided Debugging Support
The missing functionality from the WebView debugger is implemented via a proxy that gets between chrome dev tools and the debugger to fill in the blanks and to massage the conversation allowing chrome dev tools to do their magic.
JSBridge instance need to work together to provide
the essential glue. The implementation is confined to the initialization script. Most other
scripts can be oblivious to whether the
JSBridge is established or not. Console log api is one
of the missing pieces in the WebView debugger, any console log calls made before the
to Java is established will not have caller identification and will instead point to the
initialization code that played back the cached log calls generated before the connection was
JSBridge implementation also provides a mechanism for data persistence between page
reloads. It is generic enough if all the data you need to persist can be
because the implementation does a call back to the WebView engine to serialize the passed in
state argument. This text will need to be inserted into the generated HTML page to allow scripts
access to their state before the
JSBridge is hooked in. Scripts can also register for a
callback when the
JSBridge is established.
The down side of the latter approach, is by the time this happens, WebView has already visually updated the page. If the script is responsible for any visual modification of the page based on persisted state then the unmodified version will flash on screen before the script is run.
Allowing scripts to get their state before
JSBridge is established makes for smoother page
Getting Full Featured Debugging
I have not tried it with Java 9, and suspect that the debug protocol has changed and the proxy may not work with it without modifications.
However, these are the instructions to compile for Java 9 WebView debugger access as given by mohamnag/javafx_webview_debugger.
WebEngine.impl_getDebugger() is an internal API and is subject to change which is happened in
Java 9. So if you are using Java 9, you need to use following code instead to start the debug
Class webEngineClazz = WebEngine.class; Field debuggerField = webEngineClazz.getDeclaredField("debugger"); debuggerField.setAccessible(true); Debugger debugger = (Debugger) debuggerField.get(webView.getEngine()); DevToolsDebuggerServer devToolsDebuggerServer.startDebugServer(debugger, WEBVIEW_DEBUG_PORT, 0, null, null);
For this to work, you have to pass this parameter to Java compiler:
As examples, this can be done for Maven as follows:
<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>3.7.0</version> <configuration> <source>9</source> <target>9</target> <compilerArgs> <arg>--add-exports</arg> <arg>javafx.web/com.sun.javafx.scene.web=ALL-UNNAMED</arg> </compilerArgs> </configuration> </plugin>
or for IntelliJ under Additional command line parameters in Preferences > Build, Execution, Deployment > Compiler > Java Compiler.