WebView has a drag and drop eventHandler which is added to several drag events:

        setOnDragEntered(destHandler);
        setOnDragExited(destHandler);
        setOnDragOver(destHandler);
        setOnDragDropped(destHandler);

As part of this eventHandler, the dragboard content is retrieved from QuantumClipboard, which has a cache strategy in place, but unfortunately the cache is flushed away when the drag events starts (QuantumToolkit::startDrag).

This means that such content (for instance, an Image), is being retrieved from a given URL over and over again (via QuantumClipboard::readImage), on every mouse move/drag over, causing a high lag in showing the image and moving it as the drag view.

This issue can be reproduced on all platforms and JavaFX versions, but there are different cases.

On Windows and Linux, dragging an image from a web page (wrapped or not with an hyperlink) uses Clipboard::getLocalData, and QuantumClipboard::readImage tries to create a new Image(url) on every call, without background loading, which takes around 200 ms for the first image of https://openjdk.java.net.

Running the attached test from Ubuntu 20.04 with JavaFX 18-ea+6 gives:

location = https://openjdk.java.net/
DND readImage time = 407
DND readImage time = 225
DND readImage time = 226
DND readImage time = 230
location = https://openjdk.java.net/faq/
DND readImage time = 178
DND readImage time = 177
DND readImage time = 177

Similar values on Windows 10 with 18-ea+6:
location = https://openjdk.java.net/
DND readImage time = 174
DND readImage time = 173
DND readImage time = 174
DND readImage time = 178
DND readImage time = 175
DND readImage time = 176
location = https://openjdk.java.net/faq/
DND readImage time = 178
DND readImage time = 179
DND readImage time = 176
DND readImage time = 174
DND readImage time = 174
DND readImage time = 180
DND readImage time = 176


On Mac, however, SystemClipboard::popFromSystem is used.
If the image is not in an hyperlink, the load is done via pixels/rawData, which is really fast (the first image of https://openjdk.java.net. takes 2 ms) as it doesn't call new Image(url).

However, when the image is in an hyperlink (after the proposed patch for JDK-8160597 is applied), QuantumClipboard::readImage goes through new Image(url) on every call, again without background loading. For a given image, like the one on https://openjdk.java.net/projects/jdk/17/, this can take up to 700 ms.

Running the test from Mac OS 11.6 and JavaFX built from head+patch for JDK-8160597:

location = https://openjdk.java.net/
DND readImage time = 910
DND readImage time = 1
DND readImage time = 1
DND readImage time = 2
DND readImage time = 1
DND readImage time = 1
DND readImage time = 2
DND readImage time = 2
DND readImage time = 1
location = https://openjdk.java.net/faq/
DND readImage time = 1093
DND readImage time = 705
DND readImage time = 705
DND readImage time = 705
DND readImage time = 713
DND readImage time = 713
DND readImage time = 704
DND readImage time = 705

While enabling background loading of images in QuantumClipboard::readImage should make an big improvement, it seems necessary to use the linkedLists in the WebView eventHandler to cache the content, avoiding creating over and over again the same image/content.