Pages strange handling of drag'n'drop images from Chrome

Question

Level 1

10 points

Pages strange handling of drag'n'drop images from Chrome

As has been reported before, I'm referring to the odd handling of dragging an image from Chrome into Pages.

When dragging an image from Chrome into Pages, it creates a text box with the link instead of a new image. Even though you can copy/paste the image, this is still much slower and counterintuitive, and I believe it's Pages fault.

Here's the results of some of my tests:

Drag'n'Drop from Chrome to the desktop creates a file correctly.
Drag'n'Drop from Chrome to Microsoft Word adds an image correctly.
Drag'n'Drop from Chrome to Pages does the stupid link thing.
Drag'n'Drop from Safari to Pages adds an image correctly.

So to summarize, Pages has support for a proper Drag'n'Drop already, MacOS knows how to handle what Chrome is doing, Microsoft Word is able to implement the behaviour correctly, and only Pages does the wrong thing. Considering Microsoft Word and MacOS itself respond correctly, I don't believe this an issue with Chrome's implementation, but rather the fault of Pages.

In testing, Keynote and Numbers manage to bungle this as well. So this issue appears to affect all of iWork, and presumably has for at least a year, judging by this unresolved issue. Can we please get a fix for this?

Posted on Feb 27, 2020 12:10 PM

Reply

Answer 1

VikingOSX

Level 10

123,144 points

Feb 27, 2020 3:31 PM in response to Hazzardous

With Chrome v80, when you drag/drop an image (let's say it is a .png) onto Pages, Chrome is only sharing four items with the Pages application via the intermediary clipboard:

public.tiff (the raw bits, not a name)
NeXT TIFF v4.0 pasteboard type (same raw content as [1]
public.html (the URL HTML path back to the image source on the website in Chrome)
Apple HTML pasteboard type (essentially [3] again.

Firefox v73.0.1 places the same four items on the clipboard for the same image location. The difference is that Firefox is more thorough with the content in the Apple HTML pasteboard type, than Chrome, and the actual image pastes into Pages v8.2.1.

Safari 13.0.5 pastes 16 items onto the clipboard, and the original .png image from the website is encapsulated in a com.apple.flat-rtfd, and again, in the NeXT RTFD pasteboard type. It is one of these that Pages accepts to resolve drag and drop of a .png image into Pages v8.2.1. Only the Apple Pages product team knows which one.

So, back to the Chrome and Firefox versions of the Apple HTML pasteboard types:

Chrome 80 version of Apple HTML pasteboard type. Result: URI text string pasted into Pages v8.2.1.

<meta charset='utf-8'>
<img src="https://forecast.weather.gov/newimages/large/ovc.png"/>

Firefox 73.0.1 version of Apple HTML pasteboard type. Result: Image pasted into Pages v8.2.1.

<html>
<head>
   <meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body>
   <img src="https://forecast.weather.gov/newimages/large/ovc.png" alt="" class="pull-left">
</body>
</html>

As you can see, Google Chrome is not bothering with valid HTML code, omitting most of what Firefox studiously includes. I suspect this is the reason that your drag and drop from Chrome only provides a URI string in Pages v8.2.1, and not the expected image.

I don't see this as a Pages v8.2.1 application issue, but rather laziness on Google's behalf by omitting proper HTML syntax that helps Pages deposit the image, and not the resultant HTTP URI.

Reply

Answer 2

Barry

Level 9

60,023 points

Feb 27, 2020 12:39 PM in response to Hazzardous

Hi Hazz'

You are posting in a user-to-user community. The people responding to question here are users of the software and hardware being discussed, and can offer suggestions regarding using the software/hardware as it currently exists. They are not part of Apple Leadership, nor of the development teams for the software or the hardware.

Apple monitors the community for adherence to the TOU agreement, and has "Community specialists" who monitor for posts that have not gathered responses within about 24 hours of posting, and generally offer responses consisting of links to articles in the knowledge base connected with the issue identified.

While there may be workarounds for the issue you describe, the actual fix is a topic beyond the bounds of this community.

You can contact Apple directly via the Provide Pages feedback link in the Pages menu in Pages.

Regards,

Barry

Reply

Answer 3

Hazzardous Author

Level 1

10 points

Feb 27, 2020 1:13 PM in response to Barry

Thank you for your quick help! I'll be sure to share this there as well, and hopefully this can be addressed.

Reply