Closed Bug 469481 Opened 11 years ago Closed 10 years ago

Copy image doesn't copy image (nor its location)

Categories

(SeaMonkey :: UI Design, defect, minor)

x86
Linux
defect
Not set
minor

Tracking

(Not tracked)

RESOLVED FIXED
seamonkey2.0

People

(Reporter: vsego, Assigned: InvisibleSmiley)

Details

(Keywords: fixed-seamonkey2.0, regression)

Attachments

(1 file, 2 obsolete files)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20081202 SeaMonkey/2.0a2
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20081202 SeaMonkey/2.0a2

Copy image doesn't copy image (nor its location). It just clears the clipboard.

Can be worked around with "View image" and copying its location from the Location bar, but it's a bit annoying.

Reproducible: Always

Steps to Reproduce:
1. Open any web page with image(s)
2. Right-click any image
3. Click "Copy image" and try to paste it somewhere.
It won't work; clipboard is empty.
Actual Results:  
Clipboard is cleared; not image (nor its location) there.

Expected Results:  
Image URL in the clipboard.

I use KDE 4.1 (latest Fedora version)
Installed GTK: gtk+-1.2.10-66.fc9.i386, gtk2-2.12.12-1.fc9.i386
Mozilla/5.0 (Windows; U; Windows NT 6.0; cs; rv:1.9.1b3pre) Gecko/20081208 SeaMonkey/2.0a3pre

On Windows Vista is work fine.
Version: unspecified → Trunk
this was busted by bug 21747.  seamonkey has "copy image" that copies data + URL.  firefox has separate menu items for each.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
also... pasting image data part seems to work; I can paste images into gimp.
You're right, it does work like you said (copies image and not URL). I expected what I had in 1.x: copying image *location* and didn't even try pasting it into GIMP (but only konsole, gvim, gedit,...). I find c/p of image URL to be far more useful than c/p of image itself.

If I'm not mistaken, clipboard can remember several formats of data (i.e. for text: plain and formatted). Shouldn't then "copy image" remember text version (URL) and bitmap version (what it remembers now) together?

Thank you,

V.
Works for me:
Build identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.4pre) Gecko/20090915 Lightning/1.0pre SeaMonkey/2.0pre
Ubuntu 9.04
Paste application tested: OpenOffice.org 3.1.1

Test: 
http://images.google.com/images?q=1970s+boxer+source:life
o right click on first photo (Boxer Muhamad Ali sparring
1280 x 849 - 133k)
o select 'Copy Image' & past into application - works
o right click on first photo (Boxer Muhamad Ali sparring
1280 x 849 - 133k)
o select 'Copy Link Location' & past into application - works

This bug should be marked as resolved/fixed (actually invalid?) per the test + https://bugzilla.mozilla.org/show_bug.cgi?id=469481#c4 - Comment #4.
My apologies; I now better understand the issue. Testing again using http://images.google.com/images?q=1970s+boxer+source:life and using the second photo of Muhammad Ali:

In 1.1.18 if I 'Copy Image' and paste to OOo I get the image. That of
course includes the underlying URL to the photo (in this case I used the
second image to the right of Muhammad Ali) If I paste to gedit I get only
the url as gedit only handles text. The link pasted (in this case) is:
<http://t2.gstatic.com/images?q=tbn:huCex4q5kTQCuM:http://tbn0.google.com/hosted/images/c%3Fq%3D3dc5ef6334bc72e6_large>

If I repeat the above with 2.0x the image is copied as a bitmap in OOo
and the link is not available to copy into gedit. If I use Copy Link
Location in 2.0x the url ends up as:

<http://images.google.com/imgres?imgurl=http://tbn0.google.com/hosted/images/c%3Fq%3D3dc5ef6334bc72e6_large&imgrefurl=http://images.google.com/hosted/life/l%3Fimgurl%3D3dc5ef6334bc72e6&usg=__tgytc8ymFuk94hPFARRDQpmDaD0=&h=1280&w=859&sz=93&hl=en&start=2&tbnid=huCex4q5kTQCuM:&tbnh=150&tbnw=101&prev=/images%3Fq%3D1970s%2Bboxer%2Bsource:life%26hl%3Den>

And that link is considerably different than the one used in 1.1.18
'Copy Image'. It does however, match the url provided in 'Copy Link
Location' in 1.1.18.

So again, my apologies.
This is probably the easiest solution.
Assignee: nobody → jh
Status: NEW → ASSIGNED
Attachment #401518 - Flags: superreview?(neil)
Attachment #401518 - Flags: review?(neil)
I'm using the latest binary from the SeaMonkey web (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.4pre) Gecko/20090903 SeaMonkey/2.0b2). Do I need to compile it by myself to use this?

If not, can you please provide some link on how to use info from your attachment?

Thank you,

V.
Comment on attachment 401518 [details] [diff] [review]
Copy Image Location -> context menu

>+      <menuitem id="context-copyimageurl"
>+                label="&copyImageURLCmd.label;"
>+                accesskey="&copyImageURLCmd.accesskey;"
>+                oncommand="gContextMenu.copyMediaLocation();"/>
Seeing as this is only an issue on Linux, this belongs in unix/platformCommunicatorOverlay.xul; the nsContextMenu.js code can stay there though.

Also, remind me to file a core bug for the regression caused by bug 21747. As comment #4 says, Copy Image should copy bitmap, HTML and text as it correctly does on Windows.
Attachment #401518 - Flags: superreview?(neil)
Attachment #401518 - Flags: superreview-
Attachment #401518 - Flags: review?(neil)
Attached patch Unix-only fix (obsolete) — Splinter Review
(In reply to comment #8)
> I'm using the latest binary from the SeaMonkey web (Mozilla/5.0 (X11; U; Linux
> i686; en-US; rv:1.9.1.4pre) Gecko/20090903 SeaMonkey/2.0b2). Do I need to
> compile it by myself to use this?

Until a patch has been committed, you either need to compile yourself (with the patch) or modify the files locally (note that the paths are not 1:1 between the repositories and the jar files under chrome/). Once a patch has been committed the fix will be available in the next nightly build.

(In reply to comment #9)
> (From update of attachment 401518 [details] [diff] [review])
> >+      <menuitem id="context-copyimageurl"
> >+                label="&copyImageURLCmd.label;"
> >+                accesskey="&copyImageURLCmd.accesskey;"
> >+                oncommand="gContextMenu.copyMediaLocation();"/>
> Seeing as this is only an issue on Linux, this belongs in
> unix/platformCommunicatorOverlay.xul; the nsContextMenu.js code can stay there
> though.

My initial approach was a deliberate decision. I was hoping to fix this once and for all by doing it the same as FF here, providing separate menu entries for both actions on all platforms (consistency!). I think the fewer dependencies on Core/Toolkit with deviating functionality we have the better. Fixing things there requires even more approvals, time and energy than in this repository alone. Feel free to try your luck, I've learned my lesson.

> Also, remind me to file a core bug for the regression caused by bug 21747.

Please understand the above as a reminder. ;-)
Attachment #401518 - Attachment is obsolete: true
Attachment #401610 - Flags: superreview?(neil)
Attachment #401610 - Flags: review?(neil)
Attachment #401610 - Flags: superreview?(neil)
Attachment #401610 - Flags: superreview+
Attachment #401610 - Flags: review?(neil)
Attachment #401610 - Flags: review+
Comment on attachment 401610 [details] [diff] [review]
Unix-only fix

Nit: needs the comment in all three files.
Simple Unix-only regression fix/workaround.
Attachment #401610 - Attachment is obsolete: true
Attachment #401729 - Flags: superreview+
Attachment #401729 - Flags: review+
Attachment #401729 - Flags: approval-seamonkey2.0?
Attachment #401729 - Flags: approval-seamonkey2.0? → approval-seamonkey2.0+
Keywords: checkin-needed
Comment on attachment 401729 [details] [diff] [review]
Unix-only fix
[Checkin: Comment 13]


http://hg.mozilla.org/comm-central/rev/9e5dc8b22b64
Attachment #401729 - Attachment description: Unix-only fix for checkin → Unix-only fix [Checkin: Comment 13]
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Component: General → UI Design
QA Contact: general → ui-design
Resolution: --- → FIXED
Target Milestone: --- → seamonkey2.0
(In reply to comment #10)
> (In reply to comment #9)
> > Also, remind me to file a core bug for the regression caused by bug 21747.
> Please understand the above as a reminder. ;-)
Filed bug 518249.
(In reply to comment #14)
> (In reply to comment #10)
> > (In reply to comment #9)
> > > Also, remind me to file a core bug for the regression caused by bug 21747.
> > Please understand the above as a reminder. ;-)
> Filed bug 518249.
Which is now fixed, so attachment 401729 [details] [diff] [review] now needs to be backed out on trunk.
(In reply to comment #15)
> attachment 401729 [details] [diff] [review] now needs to be backed out on trunk.

http://hg.mozilla.org/comm-central/rev/5b87a8762b8b

Note that Copy Image didn't copy the image to the clipboard when I used Klipper (the KDE clipboard manager) v0.9.7 from KDE 4.3.4 and configured it to sync the clipboard with the current selection. Once I disabled that option it worked and I was able to paste to both Gimp and Kolourpaint and the clipboard contained the image URL at the same time.
You need to log in before you can comment on or make changes to this bug.