JDK-8187671 : [WebView] Drag and Drop of text or html results in an image
  • Type: Bug
  • Component: javafx
  • Sub-Component: web
  • Affected Version: 8,9,10
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2017-09-19
  • Updated: 2017-12-18
  • Resolved: 2017-09-29
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 10 JDK 8
10Fixed 8u171Fixed
Related Reports
Relates :  
Relates :  
1. Open some web page in an FX application
2. Select some text\html and drag the selected data to
    a. any browser url bar
    b. File explorer

Expected Result:
2.a The dragged text\html data should be dropped as text in browser 
2.b Should be either no-op or should get dropped as text file when pasted into file explorer

Actual Result:
2.a Drop is a image url  in browser window
2.b Drop is a png file in file manager

WebRev for backport after resolving merge conflict(Patch compiled and verified): http://cr.openjdk.java.net/~ghb/rkamath/8u/8187671/webrev.backport.00/


Changeset: cfa038af148b Author: mbilla Date: 2017-09-29 12:00 +0530 URL: http://hg.openjdk.java.net/openjfx/10-dev/rt/rev/cfa038af148b


[~ghb] Currently facing some issues in getting manual test setup to work for 10 dev. Co-working with SQE on this. Will update once that is up. [~arajkumar] I did think of exposing the DragSourceAction enum to Java layer.But i couldnt think of a use case(as yet) where we might have to handle other types differently. Also my work on JDK-8187928 might need some relook at this piece of code.

+1 + bool isImageSource = dragSourceAction & DragSourceActionImage; DragSourceAction contains few other actions also, will it be useful to pass the dragSourceAction to Java for any future usecases?

+1 with nit (WebPage.java @2269, blank line removed, No need to create another webrev if this is the only change required for further review). Tested on MacOS, and works as expected (which is mentioned in description). Do link/relate a Manual test case and add RULE in this JBS comment or in Description.

Maybe my earlier comments were a bit confusing. Clarifying on this: Cause: Currently the way WebView Drag and Drop behaves for texthtml\links. the source data is added to clipboard in these many mime types -Plaintext -Html -File type(snapshot of source) Target application always try to pick the richest data available from the Clipboard contents which it can support. Cases like url bar, search bar where file types can be pasted would end up picking the respective `file` type what we wrote Solution: Comparing the behaviors on other browsers(Chrome, Firefox, Safari) text\html\links are written to system clipboard with only these mime types ( File is not written) -Plaintext -Html So above patch, retains all the mime types we used to write earlier __except__ File type. Also, File type would continue getting added for image source where it really should be.

[~ghb] I tested using this website https://html5demos.com/drag-anything/ which lists the mime types source adds to clipboard. None of the browsers add "File" Content Type for text\html\urls\Files. FX WebView was adding "File" Content Type to Clipboard for all the content. With this change, it would be added only to image.

"The text and html data need not be added" Please test the behaviour of Safari, Chrome or Firefox by using Clipboard helper application i.e 1. Copy the content from Browser (mentioned above) 2. Use clipboard helper application which will show Clipboard object with multiple types of data. 3. If Other application ignores text and html if in case of having image in the selection list. If the above criteria is true than we can ignore "text and html data"

WebRev with the proposed fix: http://cr.openjdk.java.net/~ghb/rkamath/8187671/webrev.00/

Cause: System clipboard always tried to pick the richest data available from the Clipboard contents. In this case, the text and html data is added to clipboard in plaintext, html and finally with an image file type. So when pasting onto target application, the image file is picked up. Solution: The text and html data need not be added to clipboard with image data. This would only make sense for image source.