JDK-8087438 : [WebView] NPE when running WebEngine without WebView
  • Type: Bug
  • Component: javafx
  • Sub-Component: web
  • Affected Version: 8u45
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-06-09
  • Updated: 2020-04-03
  • Resolved: 2015-06-15
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 8 JDK 9
8u60Fixed 9Fixed
Related Reports
Duplicate :  
Duplicate :  
Description
java.lang.NullPointerException
at com.sun.javafx.Utils.getScreen(Unknown Source)
at com.sun.javafx.webkit.WebPageClientImpl.getScreenBounds(Unknown Source)
at com.sun.webkit.WCWidget.fwkGetScreenRect(Unknown Source)
at com.sun.webkit.Timer.twkFireTimerEvent(Native Method)
at com.sun.webkit.Timer.fireTimerEvent(Unknown Source)
at com.sun.webkit.Timer.notifyTick(Unknown Source)
at javafx.scene.web.WebEngine$PulseTimer.lambda$static$45(Unknown Source)
at javafx.scene.web.WebEngine$PulseTimer$$Lambda$99/3289861.pulse(Unknown Source)
at com.sun.javafx.tk.Toolkit.lambda$runPulse$30(Unknown Source)
at com.sun.javafx.tk.Toolkit$$Lambda$272/21304817.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.javafx.tk.Toolkit.runPulse(Unknown Source)
at com.sun.javafx.tk.Toolkit.firePulse(Unknown Source)
at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(Unknown Source)
at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(Unknown Source)
at com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$400(Unknown Source)
at com.sun.javafx.tk.quantum.QuantumToolkit$$Lambda$40/7640891.run(Unknown Source)
at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(Unknown Source)
at com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
at com.sun.glass.ui.win.WinApplication.lambda$null$145(Unknown Source)
at com.sun.glass.ui.win.WinApplication$$Lambda$36/20632278.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)


import javafx.application.Application;
import javafx.scene.web.WebView;
import javafx.stage.Stage;

public class MyApplication extends Application {

@Override
public void start(Stage stage) throws Exception {
                WebView view = new WebView();
                view.getEngine().load("http://www.oracle.com");
}

public static void main(String[] args) {
Application.launch(MyApplication.class);
}
}
Comments
http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/464b8efa2404
15-06-2015

Looks good to me too.
11-06-2015

+1 (and agree with Anton's comment)
11-06-2015

Looks good to me (except double space after "=").
11-06-2015

Here is the updated version: http://cr.openjdk.java.net/~anashaty/RT-46189/webrev.01/
11-06-2015

might be fixed in 8u60 (to target before push)
10-06-2015

Yes.
10-06-2015

So, what's the verdict then? Should getBounds(Object) be fixed to never return null?
10-06-2015

Since WebView isn't the only consumer of Utils.getScreen() that also argues for the consistency of having getBounds(Object) return an empty bounds, which will cause getScreen() to return the default screen; we currently never return a null from that method and might surprise other callers if we did.
10-06-2015

As far as I know WebKit itself doesn't support headless mode. At least, WebView never relied on it. So to make it headless, we simply ignore any rendering requests. In PlatformScreenJava.cpp, where the JNI fwkGetScreenRect method is called, the returned value is checked for null, in which case the native method returns IntRect(0, 0, 0, 0). So, it doesn't matter what the Java method returns, both the variants would be fine. (However, I personally would vote for an empty rect rather than null, as I asked for in RT-40764).
10-06-2015

That's a good point. getBounds(null) returns a dummy bounds of (0,0,0,0). Then perhaps the better solution is for getBounds to check Node.getLocalToScreen for null and do the same?
09-06-2015

I'm not familiar with this code, but if the problem is a null bounds then a related question is why the bounds came back null. Note that if you call getBounds(null) you get back a non-null value - it is only when you call getBounds(<Node that isn't in a scene>) where it can return a null, but that seems to me to be a bug in getBounds(). If it returns a valid object when handed a null then it should have no business returning a null for a valid input object.
09-06-2015

This isn't a webview change, so I would like Jim to review it. My only concern is that could mask a real problem where we are expecting a valid screen and don't have one. We have had other bugs that triggered this same NPE and our approach for those bugs was to not call that method if there isn't a valid screen. I'm not saying that we couldn't revisit this, but if so, let's make sure that it is the right fix.
09-06-2015

Looks like adding null check solves the problem perfectly: http://cr.openjdk.java.net/~anashaty/RT-46189/webrev.00/
09-06-2015