279270 - When right-clicking images, "copy image" copies the image location, not the image

Status: RESOLVED FIXED

(Camino Graveyard :: General, defect, P2)

Description

[Phil Tseng]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b) Gecko/20050120 Camino/0.8+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b) Gecko/20050120 Camino/0.8+

Not URL specific

Reproducible: Always

Steps to Reproduce:

Comment 1

[Mike Pinkerton (not reading bugmail)]

cute. when did this regress?

Comment 2

[Phil Tseng]

Not sure, but this bug was not present in earlier builds! :-)

Comment 3

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Into which app are you trying to paste the image?

I successfully copied the Bugzilla header image with "Copy Image" and pasted
into GraphicConverter, OmniGraffle, Photoshop 7, and NeoOffice/J Draw and Impress.

Pasting into TextEdit, Stickies, AppleWorks (Text, Drawing, Painting,
Presentation), AbiWord, and Neo/J Writer resulted in only the URL being pasted.

Copying the successfully-pasted image (e.g., from the Neo/J Impress document)
allowed it to be successfully pasted into all of the above apps where it had
failed coming straight from Camino.

Interestingly, the Finder's Edit>Show Clipboard shows only the URL and "Clipboad
contents: text" when coming right from Camino and the image and "Clipboad
contents: picture" after I had recopied the pasted image from Neo/J.

2005012108 (v0.8+), Mac OS X 10.3.7.

Comment 4

[Phil Tseng]

Interesting. I was trying to copy-paste into MS Word, and when I saw the Finder
"Show Clipboard" as the URL, I just assumed it was the same for all the other
applications.

Comment 5

[Jasper]

This regressed between januarie 8 and 12. I couldn't cehck further.

Comment 6

[Simon Fraser [no longer active]]

Probably related to bug 135300.

Comment 7

[Simon Fraser [no longer active]]

This patch:
https://bugzilla.mozilla.org/attachment.cgi?id=169964
was checked in on 1/11. Probably the culprit.

Comment 8

[Boris Zbarsky [:bzbarsky]]

So... per discussion in bug 135300, it seems that the assumption was that
"reasonable" apps would paste whichever flavor was appropriate (and give the
user a way to override if needed).

It sounds like there're a lot of "unreasonable" apps around, though....

Comment 9

[Josh Aas]

IIRC, the pasteboard works by having the app where the copy happens put an
ordered list of things on the PB.  When the paste happens, that list is walked
and the *first* one accepted by the client is used.  That patch smfr refers to
appears to first put the text, then the image--so any app accepting both gets text.

If my memory about this is correct, then just reversing the pasteboard addition
order in that patch would fix all the Mac issues--it's not that the apps are
unreasonable, it's that they are saying (to the Mac world) that the image data
is subordinate to the text, all things being equal, which is really not true here.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Er...  that's exactly what I asked about in bug 135300 comment 105, and the
response I got was very different from the information in comment 9...

Comment 11

[Simon Fraser [no longer active]]

>  When the paste happens, that list is walked and the *first* one accepted by
the client is used

This is entirely up to the application developer. Some may traverse the list in
order and take the first they find. Others may rank the flavors based on
"richness". As I argued elsewhere, text and images are not flavors of the same
bacic types (unlike plain text and html). They are very different types, and
gecko embedders need to control which goes into the clipboard.

Comment 12

[Josh Aas]

Sounds like when we copy an image, we put the image and a string on the
pasteboard and apps that look for a string first take that instead of the image.
Nothing we can do about receiving apps looking for stuff on the clipboard in a
particular order, but we could stop putting the string on the clipboard so they
have to grab the image.

So do we want to just put the image on the clipboard, or order them correctly
and hope the receiving apps grab whatever on the user wants? If we put text on
the clipboard and apps prefer that, there is nothing we can do about it.

Comment 13

[Simon Fraser [no longer active]]

See bug 135300.

Comment 14

[Simon Fraser [no longer active]]

We'll need to do some nsICommandParams stuff for CopyImage after changes in bug
135300.

Comment 15

[Simon Fraser [no longer active]]

Fixed by using nsICommand with params to specify that we only copy the image
data, not the image location.

Comment 16

[Christian :Biesinger (don't email me, ping me on IRC)]

  // by default, which we don't want. Thus se need to go directly to the command
 manger

s/se/we/ ?

Comment 17

[Simon Fraser [no longer active]]

I fixed this spelling error.

Comment 18

[Asaf Romano (gone)]

The behavior of cmd_copyImageContents has been restored, please backout.

Comment 19

[Asaf Romano (gone)]

http://tinyurl.com/7lfy4

Comment 20

[Simon Fraser [no longer active]]

What bug addresses this backout? It's not mentioned in bug 135300.

Comment 21

[Asaf Romano (gone)]

(In reply to comment #20)
> What bug addresses this backout? It's not mentioned in bug 135300.

see bug 291110

Comment 22

[Simon Fraser [no longer active]]

Unused nsICommandParams code removed.