Closed
Bug 279270
Opened 20 years ago
Closed 19 years ago
When right-clicking images, "copy image" copies the image location, not the image
Categories
(Camino Graveyard :: General, defect, P2)
Tracking
(Not tracked)
RESOLVED
FIXED
Camino0.9
People
(Reporter: tsengp, Assigned: sfraser_bugs)
References
Details
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:
Reporter | ||
Comment 2•20 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.
Reporter | ||
Comment 4•20 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 applications.
Assignee | ||
Comment 6•20 years ago
|
||
Probably related to bug 135300.
Assignee | ||
Comment 7•20 years ago
|
||
This patch: https://bugzilla.mozilla.org/attachment.cgi?id=169964 was checked in on 1/11. Probably the culprit.
Comment 8•20 years ago
|
||
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....
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•20 years ago
|
||
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...
Assignee | ||
Comment 11•20 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•19 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.
Assignee | ||
Comment 14•19 years ago
|
||
We'll need to do some nsICommandParams stuff for CopyImage after changes in bug 135300.
Assignee: pinkerton → sfraser_bugs
Assignee | ||
Updated•19 years ago
|
Status: NEW → ASSIGNED
Priority: -- → P2
Assignee | ||
Comment 15•19 years ago
|
||
Fixed by using nsICommand with params to specify that we only copy the image data, not the image location.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Comment 16•19 years ago
|
||
// by default, which we don't want. Thus se need to go directly to the command manger s/se/we/ ?
Assignee | ||
Comment 17•19 years ago
|
||
I fixed this spelling error.
Comment 18•19 years ago
|
||
The behavior of cmd_copyImageContents has been restored, please backout.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 19•19 years ago
|
||
http://tinyurl.com/7lfy4
Assignee | ||
Comment 20•19 years ago
|
||
What bug addresses this backout? It's not mentioned in bug 135300.
Comment 21•19 years ago
|
||
(In reply to comment #20) > What bug addresses this backout? It's not mentioned in bug 135300. see bug 291110
Assignee | ||
Comment 22•19 years ago
|
||
Unused nsICommandParams code removed.
Status: REOPENED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•