On Fri, 14 Nov 2025 22:04:30 GMT, Kevin Rushforth <[email protected]> wrote:
> The NPE being hit by the test program is coming because `setScene(null)`,
> which is called on the FX app thread, will lead to calling
> `HostContainer::setEmbeddedStage(null)` and
> `HostContainer::setEmbeddedScene(null)`. Those methods will set the
> `stagePeer` and `scenePeer` fields to null. Meanwhile, a repaint operation or
> a mouse move or ... on the EDT could be trying to access the scene peer.
Yes, the test does this
for (int i = 0; i < 300; i++) {
SwingUtilities.invokeLater(contentPane::repaint);
Platform.runLater(() -> contentPane.setScene(null));
Thread.sleep(100);
Platform.runLater(() -> contentPane.setScene(webView.getScene()));
Thread.sleep(100);
}
so when FX thread calls `setScene(null)`, the `stagePeer` and `scenePeer`
fields are set to null through `HostContainer.setEmbeddedStage(null)` and
`HostContainer::setEmbeddedScene(null)` as mentioned and when
`HostContainer.setEmbeddedStage` calls `stagePeer.setFocused` on EDT, it
crashes
and if the thread sleep is reduced to 1ms from 100ms, there might be a chance
that `repaint` can get scheduled on AWT thread on context switch, it calls
`JFXPanel.paintComponent` which tries to access "`scenePeer.getPixels`" which
can cause NPE.
So, I have stored the "stagePeer" and "scenePeer" to temp variable whenever the
method is supposedly called on EDT like `processXXXEvent `and `sendxxxEventToFX`
Also, additionally I see that `sendxxxEventToFX` is being called on EDT except
`sendMoveEventToFX` which is called in couple of places in FX thread, which is
now modified to being called in EDT in all places
Also, removed the debug logging
-------------
PR Comment: https://git.openjdk.org/jfx/pull/1968#issuecomment-3542802414
