JDK-8187726 : [WebView] Copy and Paste of Image not resulting in expected behavior
  • Type: Bug
  • Component: javafx
  • Sub-Component: web
  • Affected Version: 8,9,10
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2017-09-20
  • Updated: 2017-10-19
  • Resolved: 2017-10-10
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 8-poolResolved
Related Reports
Relates :  
Relates :  
Description
Scenario:
1. Open a html page containing an image in FX WebView application
2. Right Click on the image. Context Menu pops up. Select "Copy Image to Clipboard"
3. Try pasting the image like below
    a. Navigate to any paint application. Paste the image.
    b. Navigate to file explorer. Try pasting the image. 

Expected Result:
3.a Image should be pasted successfully into the paint canvas
3.b Image should be dumped as a file into the file explorer.

Actual Result:
3.a Image is pasted fine
3.b Nothing happens

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

+1
19-10-2017

Changeset: dedd5afd753e Author: mbilla Date: 2017-10-10 19:49 +0530 URL: http://hg.openjdk.java.net/openjfx/10-dev/rt/rev/dedd5afd753e
10-10-2017

+1 with below nit: Please correct copy right header (to 2017) in PasteboardImpl.java
10-10-2017

+1
10-10-2017

[~arajkumar] Tried code changes with your suggestion. Added package private methods in WebPage to get the ContextMenuController object and then invoke copy operation by a helper. But this has other roadblocks. 1.To invoke a copy operation, `context` object needs to be initiated failing which any context menu operation would fail. We can simulate a "rightclick event" on a node using initMouseEvent but this would not initiate the `context` object in WebCore. This ultimately led to a crash inside WebKit. 2. Could workaround (1) by simulating a "contextmenu event" instead. In this case, "contextmenu event" would trigger event handlers to initiate `context` object. However, this does not emulate a real right click as the context menu dialog does not show up(This is true for all browsers). With this approach `context` object crash could be overcome but the WebCore Element information (required to actually extract the image details) is not populated in the `context` internals. Because of this, image copy wouldn't happen.
07-10-2017

For the unit test, probably try to use the WebCore::ContextMenuController::contextMenuItemSelected. You can get WebCore::ContextMenuController object from WebCore:Page object.
29-09-2017

[~ghb] Resolution Issue: It is User Agent related. For our user agent we are getting different image. Checked by changing user agent in Chrome and got the same resolution image as seen in FX WebView. "Paste" Option in Finder on OS X : Copy image from other browsers is not enabling the "Paste" option. Not sure why they dont. But with this patch in FX,"Copy Image to Clipboard" will enable the "Paste" option in Finder.
27-09-2017

Changes looks good to me. Do check the behaviour on Windows and Linux for below. On OS X, with Firefox, Chrome and Safari. 1. search "oracle" in google.com and navigate to images 2. Selected the first image (which was 400x400 png from twitter log which was a jpeg image), Context menu --> "Copy image to clipboard" 3. Pasted on Email editor >Works , but the resolution doesn't match with the same behaviour of Step 2 in comparison with Firefox, Chrome and Safari. Pasting from these 3 browser maintains the resolution, where as our image pasted from WebView size is little different. 4. Pasted on Finder (Do check on File Explorer in windows and on "Files" in Ubuntu or any other flavour of Linux). WebView : creates a jfx123123123.png (123123... random long number), no matter what type of image is being copied from WebView is pasted as .png, this is already tracked in JDK-8187928. Other browser : Not paste option in Finder. This might be only on OS X and with Finder.
27-09-2017

[~ghb] Tried writing JUnit for this with two approaches but could not get the desired outcome: 1. Capturing image in html page using JS focus and copy - This does not work because script does not let copy of images due to security reasons. 2. Simulating Context Menu click for "Copy Image to Clipboard" - WebKit context menu does not directly inherit from FX contextmenu. To simulate we would need indexing into the context menu items. But that is not possible because WebKit wrapper does not have methods exposed. The write of image in source file format for both "Copy n Paste" and "Drag n Drop" will be handled here https://bugs.openjdk.java.net/browse/JDK-8187928
25-09-2017

[~ghb] -Will try a JUnit for this. -Regarding writing with source image type, yes thats a good suggestion. I went by how it was implemented for drag n drop currently. It should be doable considering ImageIO capabilities of writing multiple types. -Yes its tested on all platforms. Only thing is on Linux the image would not write to the file manager. But this was true for other browsers i tested as well.
22-09-2017

Is it difficult to have JUnit for this fix ? ref HTMLEditingTest.clipboardGetDataOnPaste Copying any (Supported) type of image from WebView will be created with .png as of now ? can't we get the image type and associate the correct extn ? I believe its tested on all 3 platform.
22-09-2017

Issue: Currently, Copy and Paste of image populates only image mime type to clipoard. This is fine as long as we paste the content to graphical editors. But for pasting the image as a file in `File explorer` requires a write of the image as a file as well. Fix: Clipboard is populated with file type and corresponding snapshot of image. WebRev for review: http://cr.openjdk.java.net/~ghb/rkamath/8187726/webrev.00/
21-09-2017