vsch / Javafx-WebView-Debugger

Full Featured Google Chrome Dev Tools to JavaFX WebView browser debugging.
MIT License
65 stars 11 forks source link

Console not working #1

Open stathissideris opened 6 years ago

stathissideris commented 6 years ago

While running the WebViewDebugSample, I tried evaluating console.log("dwqdqdQ") in Chrome developer tools, and I got this exception in the Java console:

Exception in thread "JavaFX Application Thread" netscape.javascript.JSException: ReferenceError: Can't find variable: __api
    at com.sun.webkit.dom.JSObject.fwkMakeException(JSObject.java:128)
    at com.sun.webkit.WebPage.twkExecuteScript(Native Method)
    at com.sun.webkit.WebPage.executeScript(WebPage.java:1427)
    at javafx.scene.web.WebEngine.executeScript(WebEngine.java:948)
    at com.vladsch.javafx.webview.debugger.DevToolsDebuggerJsBridge$JfxDebuggerAccessImpl.eval(DevToolsDebuggerJsBridge.java:330)
    at com.vladsch.javafx.webview.debugger.DevToolsDebugProxy.sendMessage(DevToolsDebugProxy.java:1075)
    at com.vladsch.javafx.webview.debugger.DevToolsDebuggerServer$1.run(DevToolsDebuggerServer.java:264)
    at com.sun.javafx.application.PlatformImpl.lambda$null$170(PlatformImpl.java:295)
    at com.sun.javafx.application.PlatformImpl$$Lambda$49/1545911266.run(Unknown Source)
    at java.security.AccessController.doPrivileged(Native Method)
    at com.sun.javafx.application.PlatformImpl.lambda$runLater$171(PlatformImpl.java:294)
    at com.sun.javafx.application.PlatformImpl$$Lambda$48/1567581361.run(Unknown Source)
    at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95)

Also, the click events logging shows up in the WebViewDebugSample window, but not in Chrome developer tools. Changing the document from the Elements tab in Chrome developer tools works as expected (all changes are reflected back to the WebViewDebugSample window).

Same behaviour was seen in my application.

My setup:

On OSX 10.13.2 (17C205)

Google Chrome is up to date Version 66.0.3359.117 (Official Build) (64-bit)

java -version java version "1.8.0_45" Java(TM) SE Runtime Environment (build 1.8.0_45-b14) Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)

vsch commented 6 years ago

@stathissideris, I have to try it with latest chrome and High Sierra. Something could have changed in the way chrome tool communicates with the debugger. The implementation is heuristic and I could have missed something.

However, the java version of 1.8.0_45 is suspect because JavaFX WebView became barely usable in 1.8.0_40 and the WebViewDebugSample won't compile at that version. There have been a lot of changes in WebView in later releases.

I ran my testing with 1.8.0_162, 151, 102 and got as low as 1.8.0_77. I have to download 45 before I can try it.

Console logging works in 1.8.0_77 from JavaScript and from DevToolsConsole. same for 1.8.0_102, 151 and 162.

I'll try the Java version 1.8.0_45 first. It most likely will not work with this early version.

I noticed that establishing the connection takes a bit of time after DevTools connects from Chrome and a reload is done for the first time in the WebViewDebugSample.

BTW, You need to first do a Page reload from the WebViewDebugSample after the debugger is connected so it injects the JS code to handle the logging into the page. Without the debugger connected the page is plain HTML.

I also found a bug in the console code execution which uses the wrong JSON string function and does not unescape the \" so single quoted arguments from DevTools console.log will work while double quoted will generate an exception. I'll make a release with a fix for that.

stathissideris commented 6 years ago

I upgraded my Java to this

java version "1.8.0_172" Java(TM) SE Runtime Environment (build 1.8.0_172-b11) Java HotSpot(TM) 64-Bit Server VM (build 25.172-b11, mixed mode)

And I did the reload as you advised (I hadn't realised that I had to!) but I still get the same behaviour. I also tried logging with single quotes but still no luck!

vsch commented 6 years ago

@stathissideris, I forgot about the reload changing the page too. It has been a while since I took a look at that code.

I will have to try it under parallels on High Sierra, and also with latest chrome. I was using 63. Since this is highly dependent on the communications between dev tools and the debugger, if they changed something in the sequence or how they handle the response it could have an effect.

stathissideris commented 6 years ago

Thanks for looking into this! I do see element highlighting when moving the mouse over the tree in the dev tools, neat!

vsch commented 6 years ago

@stathissideris, if you do the following:

  1. start debug server from the context menu in the sample debug app,

  2. then copy the URL (context menu),

  3. open chrome, and paste the URL, HIT enter

  4. You should see the chrome connected

  5. In websample, reload page

  6. After a delay you should see the console log in chrome:

    screen shot 2018-04-24 at 11 10 39 am
  7. Click in the webview sample and you should see the click events in the devtools log:

    screen shot 2018-04-24 at 11 10 50 am

Do you get that far?

stathissideris commented 6 years ago

I'm not sure if it helps, but to give you some extra info: From my application, I can evaluate 2+2 in the dev tools console (which I could not with your sample), but when I try console.log('foo') I get a ReferenceError: Can't find variable: arguments in the dev tools console and no Java exception. I don't know what I doing differently in my app, but the behaviour is different (it's in Clojure).

stathissideris commented 6 years ago

Nope, in your sample app step 6 still looks like this (I did 2 reloads) screen shot 2018-04-24 at 18 14 45

vsch commented 6 years ago

@stathissideris, the console log evaluation is a recursive web. The request comes in with the JS Object, it needs to be available in JS code, so it is saved in Java and retrieved with a Java/JS bridge function from JS so it can be evaluated.

All this occurs through the debugger API async from Java with a lot of synchronization required to prevent the debug interface from getting recursed into without it expecting it.

I will take a look at the code and see if I missed something. In the last two months I spent all my time brushing up on JavaScript and I am in a better position to think JS.

vsch commented 6 years ago

@stathissideris, it definitely is not getting the debugger synchronized and logging connected.

Are you getting console log output if you invoke it from the page JS, just add some script to log on click or something.

I got latest chrome installed and will test it now.

stathissideris commented 6 years ago

OK great. To be honest, I'm starting to feel a bit disappointed with how hostile JavaFX is to developers, I'm seriously considering switching to Electron at this stage!

stathissideris commented 6 years ago

But thanks for your efforts in any case!

vsch commented 6 years ago

@stathissideris, JavaFX is great, unless you need to debug JS in it. Before I got the debugging hooked in it was a nightmare of adding logs everywhere in the code to figure out what was going on.

It is still a bit of a trial and error process to figure out what is going on in new setups.

I can't blame you for not wanting to waste time on it if you have other alternatives. In my case I had no choice.

Wait till you start displaying images and encounter its caching from now to the end of time. Really significant if you have large images. It tends to cache everything and the only way to clear it is to close the app.

vsch commented 5 years ago

This was fixed. The error was caused by lambda code accessing arguments which was ok in previous javafx versions but in a later update became an error. Changed lambdas to anonymous functions to fix the issue.