Closed Bug 749527 Opened 12 years ago Closed 12 years ago

When trying to 'copy' a picture directly from Firefox into a windows live chat box, it copys the image location (link) instead of the image.

Categories

(Firefox :: Untriaged, defect)

12 Branch
x86
Windows 7
defect
Not set
minor

Tracking

()

RESOLVED FIXED
Firefox 15
Tracking Status
firefox12 --- affected
firefox13 + verified
firefox14 + verified
firefox15 --- verified

People

(Reporter: danielcspencer, Assigned: bbondy)

References

Details

(Keywords: regression, Whiteboard: [qa+])

Attachments

(1 file, 1 obsolete file)

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20100101 Firefox/12.0
Build ID: 20120420145725

Steps to reproduce:

Attempted to share a picture to a windows live chat box ( right clicked and clicked 'copy'  then in the chat box, 'pasted')


Actual results:

When after clicking 'paste' in the chat box after right clicking copy on an image, it copied the image location and instead of showing the picture in the chat box.


Expected results:

It should have shown the image, rather than the image location. Normally to get the image location i would have to press 'copy image location'  but in this case, 'copy' was used, and it still gave me the image location without showing the picture. 

(please note that before the latest update, the image would show with 'copy' and 'paste'.)
Severity: normal → minor
Group: core-security
I also experienced in Wordpad.
This may be same root problem.

Step To Reproduce:
1. Open http://www.mozilla.org/en-US/projects/
2. Right click on Firefox Icon and exec"Copy Image"
3. Open Wordpad (wordpad.exe)
4. Execute Paste Ctrl+V

Actual results:
  URL is pasted

Expected results:
  Image is pasted

Regression window(m-c)
Works(image is pasteed):
http://hg.mozilla.org/mozilla-central/rev/200a8d1fb452
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20120104 Firefox/12.0a1 ID:20120104031035
Fails(image url is pasteed):
http://hg.mozilla.org/mozilla-central/rev/0eec6ba6a87a
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20120104 Firefox/12.0a1 ID:20120104042859
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=200a8d1fb452&tochange=0eec6ba6a87a

Regression window(m-i)
Works(image is pasteed):
http://hg.mozilla.org/integration/mozilla-inbound/rev/d26fad81f51a
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20120103 Firefox/12.0a1 ID:20120103191255
Fails(image url is pasteed):
http://hg.mozilla.org/integration/mozilla-inbound/rev/06de54d7d7b4
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20120103 Firefox/12.0a1 ID:20120103195355
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=d26fad81f51a&tochange=06de54d7d7b4
Suspected:
52d9d7bbfad1	Brian R. Bondy — Bug 555176 - Provide the same formats we do on drag when copying images. r=jimm
Blocks: 555176
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
I think this happens because wordpad and msn messenger choose to use the wrong clipboard format.  They take the text format before the HTML format.  We could fix this by not providing the text format for that operation while still providing the HTML format that caused GMail to not accept images originally.
Attached patch Patch 1. (obsolete) — — Splinter Review
So a bit of history on this bug:
- First we only supplied CF_DIB format so we didn't work with pasting to gmail
- Then I added in all image formats so the application could pick the most appropriate
- But now some applications choose the wrong format

So it is best to supply CF_DIB and CF_HTML on copy image operations. This is the same as Google Chrome and IE does.
Assignee: nobody → netzen
Attachment #619045 - Flags: review?(ehsan)
Comment on attachment 619045 [details] [diff] [review]
Patch 1.

Review of attachment 619045 [details] [diff] [review]:
-----------------------------------------------------------------

Why are you not changing the behavior of cmd_copyImage, so that this fix gets applied everywhere that command is used?
> Why are you not changing the behavior of cmd_copyImage

Basically for the fear of having unknown side effects, such as in extensions.

This menu item didn't originally use cmd_copyImage, it used cmd_copyImageContents.
It was changed to cmd_copyImage when we wanted to support pasting to gmail.

Please let me know your preference:
- leave as is with the new command option that leaves the old ones unchanged (safest but leaves room for future errors)
- make cmd_copyImage and cmd_copyImageContents copying the image data + html format (safest for not breaking anything in extensions and for making sure they probably do the right thing)
- Remove cmd_copyImageContents and put the new functionality in cmd_copyImage
- Something else.


Thanks!
I'll go ahead with keeping the change from Bug 555176 to keep the menu item command change, while modifying what it means to cmd_copyImage.  This seems like the best option overall.
Attached patch Patch v2. — — Splinter Review
Attachment #619045 - Attachment is obsolete: true
Attachment #619045 - Flags: review?(ehsan)
Attachment #619295 - Flags: review?(ehsan)
This is also a problem in Corel PhotoPaint. If I right-click on an image in FireFox 12, and then choose 'New From Clipboard' in PhotoPaint, it copies the URL, not the image.
Comment on attachment 619295 [details] [diff] [review]
Patch v2.

Review of attachment 619295 [details] [diff] [review]:
-----------------------------------------------------------------

I think this makes sense.
Attachment #619295 - Flags: review?(ehsan) → review+
After this regression, "Copy Image" is functionally identical to "Copy Image Location".
Copy Image will add all of the clipboard formats, Copy Image Location will not.  So it depends on which application you are pasting to.  Some will for example choose the image data that is available on the clipboard.  In any case the patch that was recently r+ will be pushed soon and I will request to move it up in aurora and beta.
https://hg.mozilla.org/mozilla-central/rev/83da4dad7aea
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 15
Firefox 15?? Can it be pushed out any sooner?
Just a note that Copy and Paste is also broken in:
Corel PhotoPaint X4 (New from Clipboard)
CorelDraw X4 

And from what I've read on the forum:
Corel PhotoPaint X5 (current version. Don't know about CorelDraw X5.)
Adobe Illustrator CS3
InDesign
MS Windows Live Writer
One member said that it was broken with Word, but it works with my version which is 2002.
> Firefox 15?? Can it be pushed out any sooner?

I'll be requesting this for aurora and beta, but it just had to land in the nightly channel first.  So likely it will be included in v13.
Comment on attachment 619295 [details] [diff] [review]
Patch v2.

[Approval Request Comment]
Regression caused by (bug #):  555176 
User impact if declined: Pasting will not work as expected for images in some programs. 
Testing completed (on m-c, etc.): I've tried it on m-c.
Risk to taking this patch (and alternatives if risky): Very low.
String changes made by this patch: None.
Attachment #619295 - Flags: approval-mozilla-beta?
Attachment #619295 - Flags: approval-mozilla-aurora?
Comment on attachment 619295 [details] [diff] [review]
Patch v2.

[Triage Comment]
Approved for Beta 13 and Aurora 14 given the low risk nature of the fix, and the undesirable user experience.
Attachment #619295 - Flags: approval-mozilla-beta?
Attachment #619295 - Flags: approval-mozilla-beta+
Attachment #619295 - Flags: approval-mozilla-aurora?
Attachment #619295 - Flags: approval-mozilla-aurora+
Just FYI, it looks like FF Beta 13 as of yesterday included some changes related to this, and they introduced yet another variation (not sure if the patches here fix it) - copying an image in FF13B and pasting into something like Windows Live Writer copied it inline (as in, base64 encoded image, something like <img src="data:image/png;base64,...), which is better than copying an <img> tag and hotlinking but not as good as it used to be.
Re Command 19:

Tested with beta tip and it is working in wordpad, word2010, gmail
https://hg.mozilla.org/releases/mozilla-beta/rev/4ed2dffc85cd
Tested copy and paste with FF 2013.0b2 and Aurora 14.0a2
(I don't know if these are the latest builds.)

Corel Photopaint X4 still pastes the URL of the image when pressing "New from clipboard" and also pastes the URL into an existing document via "Paste" or CTRL_V hotkey.
CorelDraw X4 pastes the URL as well, but has the option to paste as a device independent bitmap in the menu. (Same functionality as Wordpad.)
You will have to wait until the next build on these channels, this just landed.
Thanks Brian.
Confirming that Copy and Paste functionality has been restored for both Corel X4 applications in Aurora 14.0a2 (2012-05-05).
I haven't tested Firefox 13 beta as the "Check for Update" function still says the version I tested previously is the latest.
Much appreciated.
This seems to have caused a regression in SeaMonkey. Not sure how to resolve this since this is wanted behaviour in Firefox.
Depends on: 752505
Indicated how you should fix that in SeaMonkey in that bug.  This fix should stay the same here.
Whiteboard: [qa+]
Verified as fixed on:
Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20100101 Firefox/13.0
(buildID: 20120509070325)

The image is copied and pasted without any issues in Windows Live Writer and Mail, Wordpad, Gmail.
Please note that this is not program specific. The is issue is from Firefox(v12) to the clipboard that is the problem.  Try to copy any image and go Run "clipbrd" you will only see the link, so the problem has nothing to do with corel, office, or any other program.
This is already fixed and verified in v13.  The regression was that Firefox provides an extra data format and those programs choose to use a format that you didn't expect.  To solve this problem we are providing less choices.
> we are providing less choices
"fewer choices" or "less choice"
Verified as fixed on:
Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20100101 Firefox/14.0 (20120605113340)

The image is copied to the clipboard when selecting "Copy Image" from Firefox.
For the record: https://support.mozilla.org/en-US/questions/926093 (especially the 3rd page with last messages)
Also verified on:
Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20100101 Firefox/15.0

Verified with some of the links on the support page from the above comment. All the images were copied to the clipboard when clicking "Copy Image" in Firefox.
Depends on: 796346
Imo, you are attempting to fix bugs in external programs by fixing a non-bug in Firefox.

It is the job of the program doing the paste to choose which part of the copy-paste buffer to use for the paste. If they do not do it correctly, it is THEIR fault and THEIR problem, not Firefox's.

-----

"Copy Image" should copy ALL (3) 'versions' of an image, not just the image.

"Copy Image Location" should ONLY copy the text URL address or location.
"Copy Image Content" should ONLY copy the image.

There should also be a "Copy Image HTML" command.

-----

By "fixing" this, you have actually broken it, and reverted to the incorrect functionality that was fixed before in Bug 518249.

At the very least, although imo it is not correct, if you were to do as was done in this Bug 'fix', there should have been a new command added called "Copy Image All" to replace the reverted functionality. (however, that is confusing imo because it really should be as stated above)
Bug 518249 is a GTK specific bug as far as I can tell.

Do you know of any other programs that would copy textual data when you invoke a copy image command?
Off hand, I can't think of any. However, I was sure there were some, if not many.

However, perhaps the "standard" has changed. Back when I was doing Windows programming, unless I am not remembering correctly, I thought part of the point of supporting multiple format storage ability in the (Windows) clipboard was to support the concept of allowing applications to be able to copy and paste whatever native format(s) was/were supported by the app, and/or might be supported by other apps.

So, for example, a text editor would only copy and paste text, or paste the text portion of the clipboard and ignore the rest. An graphics program would act similarly with images, or, for example, if you were in "text creation mode", use the text portion. A more multi-media app would perhaps choose a most-used format, with some way to support other formats, if the app supported them. ('word processors', etc.)

Although the following is from the eVile Wikipedia, I thought this was still the standard:

http://en.wikipedia.org/wiki/Clipboard_%28computing%29

''When data is added to the clipboard by an application, it typically makes it available in as many different data formats as it can. This includes both native and simpler (or more common) formats that would have a higher chance of being recognized by a wide variety of applications. Thus, when data is pasted into another application, the format that is closest to that application's native format can be used, preserving as much of the original data as possible. In Windows in particular, the internal clipboard functionality of the operating system will automatically translate data from known advanced formats to simpler formats (such as RTF to plain text, or Unicode to ANSI Text), increasing the likelihood that any given application can interpret some form of the original data.''

>>>>>

If the changes made by the bug fix stand, what is the possibility of getting the 'cmd_copyImageAll' functionality added? (and when?)
(In reply to OMR from comment #38)
> Off hand, I can't think of any. However, I was sure there were some, if not
> many.
> 
> However, perhaps the "standard" has changed. Back when I was doing Windows
> programming, unless I am not remembering correctly, I thought part of the
> point of supporting multiple format storage ability in the (Windows)
> clipboard was to support the concept of allowing applications to be able to
> copy and paste whatever native format(s) was/were supported by the app,
> and/or might be supported by other apps.
> 
> So, for example, a text editor would only copy and paste text, or paste the
> text portion of the clipboard and ignore the rest. An graphics program would
> act similarly with images, or, for example, if you were in "text creation
> mode", use the text portion. A more multi-media app would perhaps choose a
> most-used format, with some way to support other formats, if the app
> supported them. ('word processors', etc.)
> 
> Although the following is from the eVile Wikipedia, I thought this was still
> the standard:
> 
> http://en.wikipedia.org/wiki/Clipboard_%28computing%29
> 
> ''When data is added to the clipboard by an application, it typically makes
> it available in as many different data formats as it can. This includes both
> native and simpler (or more common) formats that would have a higher chance
> of being recognized by a wide variety of applications. Thus, when data is
> pasted into another application, the format that is closest to that
> application's native format can be used, preserving as much of the original
> data as possible. In Windows in particular, the internal clipboard
> functionality of the operating system will automatically translate data from
> known advanced formats to simpler formats (such as RTF to plain text, or
> Unicode to ANSI Text), increasing the likelihood that any given application
> can interpret some form of the original data.''

Well the reality is that many Windows programs do not really expect image data to also accompany textual data, which is what this bug is about.  It's a sucky situation indeed.

> If the changes made by the bug fix stand, what is the possibility of getting
> the 'cmd_copyImageAll' functionality added? (and when?)

We can do that in bug 796346.  I'll morph it.
@OMR
According to comment #29 above;
[quote]
Please note that this is not program specific. The is issue is from Firefox(v12) to the clipboard that is the problem.  Try to copy any image and go Run "clipbrd" you will only see the link, so the problem has nothing to do with corel, office, or any other program.
[/quote]
I imagine that the poster was using Windows XP.
I never checked this with Vista or 7.
You need to log in before you can comment on or make changes to this bug.