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
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.
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.
This regressed between januarie 8 and 12. I couldn't cehck further.
Probably related to bug 135300.
This patch: https://bugzilla.mozilla.org/attachment.cgi?id=169964 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....
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...
> 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.
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.
We'll need to do some nsICommandParams stuff for CopyImage after changes in bug 135300.
Assignee: pinkerton → sfraser_bugs
Fixed by using nsICommand with params to specify that we only copy the image data, not the image location.
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
// by default, which we don't want. Thus se need to go directly to the command manger s/se/we/ ?
I fixed this spelling error.
The behavior of cmd_copyImageContents has been restored, please backout.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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
Unused nsICommandParams code removed.
Status: REOPENED → RESOLVED
Last Resolved: 14 years ago → 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.