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



14 years ago
14 years ago


(Reporter: tsengp, Assigned: sfraser_bugs)






14 years ago
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:
cute. when did this regress?
Target Milestone: --- → Camino0.9

Comment 2

14 years ago
Not sure, but this bug was not present in earlier builds! :-)
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

14 years ago
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

Comment 5

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


14 years ago
Ever confirmed: true

Comment 6

14 years ago
Probably related to bug 135300.

Comment 7

14 years ago
This patch:
was checked in on 1/11. Probably the culprit.
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

14 years ago
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.
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

14 years ago
>  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

14 years ago
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

14 years ago
See bug 135300.
Depends on: 135300

Comment 14

14 years ago
We'll need to do some nsICommandParams stuff for CopyImage after changes in bug
Assignee: pinkerton → sfraser_bugs


14 years ago
Priority: -- → P2

Comment 15

14 years ago
Fixed by using nsICommand with params to specify that we only copy the image
data, not the image location.
Last Resolved: 14 years ago
Resolution: --- → FIXED
  // by default, which we don't want. Thus se need to go directly to the command

s/se/we/ ?

Comment 17

14 years ago
I fixed this spelling error.
The behavior of cmd_copyImageContents has been restored, please backout.
Resolution: FIXED → ---

Comment 20

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

see bug 291110

Comment 22

14 years ago
Unused nsICommandParams code removed.
Last Resolved: 14 years ago14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.