Add cmd_copyImageContentsAndHTML

RESOLVED WONTFIX

Status

()

Firefox
Extension Compatibility
RESOLVED WONTFIX
6 years ago
6 years ago

People

(Reporter: Bill Dee, Unassigned)

Tracking

({addon-compat, regression})

15 Branch
x86_64
Windows 7
addon-compat, regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

6 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20100101 Firefox/15.0.1
Build ID: 20120905151427

Steps to reproduce:

An extension (Image Toolbar) that uses the goDoCommand ('cmd_copyImage') function feature used to work prior to Firefox version 15 and now works differently than expected.


Actual results:

That command now ONLY copies the image to the copy/paste buffer, and NOT the location (URL of the image as text) or the HTML source of the image, like it used to prior to Firefox version 15.


Expected results:

It is supposed to copy all three representations of the image to the copy/paste buffer. 

Bug 518249 - Allow cmd_copyImage to copy all three representations of the image, was marked Status: 	RESOLVED FIXED circa 2010-04-05.

This functionality has now reverted to working the way it worked prior to the Bug 518249 fix.
(Reporter)

Comment 1

6 years ago
If there is a temporary work-around for this, please let us know ASAP. Thanks.
(Reporter)

Comment 2

6 years ago
For more information, see: http://forums.mozillazine.org/viewtopic.php?f=9&t=2560031
See Also: → bug 518249

Updated

6 years ago
Component: Untriaged → Extension Compatibility

Updated

6 years ago
Component: Extension Compatibility → Untriaged

Comment 3

6 years ago
Mozregression range:

m-c
good=2012-05-02
bad=2012-05-03
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b13bfc70bc44&tochange=807403a04a6a

m-i
good=2012-04-30
bad=2012-05-01
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=330f6adec1ec&tochange=32e001c1351b

Suspected bug: 
Brian R. Bondy — Bug 749527 - Remove text formats in clipboard when copying an image. r=ehsan.

There was a discussion about cmd_copyImage and cmd_copyImageContents in this bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=749527#c5
Status: UNCONFIRMED → NEW
Component: Untriaged → Extension Compatibility
Ever confirmed: true
Keywords: regression
See Also: bug 518249

Comment 4

6 years ago
(I used this add-on and its image copy feature: https://addons.mozilla.org/en-US/firefox/addon/image-toolbar/ )
Ehsan, how do you want this to work?  I originally created a  new comment for this but in Bug 749527 Comment 4 you asked me to change the handling of cmd_copyImage.

We could also just leave it as is and suggest to the addon author to update their code to use cmd_copyImageLocation instead.

Updated

6 years ago
Blocks: 749527
Keywords: addon-compat

Comment 6

6 years ago
I still think that what we did in bug 749527 makes sense.  OMR, any chance you could update your extension to work around this, please?  Thanks!
(Reporter)

Comment 7

6 years ago
I'm not anywhere near 'fluent' (or even proficient) in extension programming, or the use of Firefox internals.

I tried this:

goDoCommand ('cmd_copyImage');
goDoCommand ('cmd_copyImageLocation');

But of course it didn't work the way I hoped, because the second call overrode the first.


If you really want it to work the way it has been changed to work, you really need a new command:

goDoCommand ('cmd_copyImageAll');


***** As a work-around, does anyone know how I could perhaps use cmd_copyImageLocation to get the URL address and then cmd_copyImage to get the image, and then just update the text part of the copy/paste buffer???

That would work if it can be done. Thanks for any help/hints/suggestions.

==========

btw -- I STRONGLY disagree that what was done in the Bug 749527 'fix' makes sense or was the correct course of action.

I made what I think is a very valid point, and the ideal, correct descriptive features and functionality definition that should be used and in place, in the Bug 'fix' that reverted the functionality of the cmd_copyImage command here:

https://bugzilla.mozilla.org/show_bug.cgi?id=749527#c36

Comment 8

6 years ago
As I said in bug 749527 comment 37, what matters here is whether applications stick in textual data on the clipboard alongside with image data when you want to copy an image.  I don't know of any application which does that off-hand.
Ehsan, perhaps we should morph this bug to add a new command to copy everything?

Comment 10

6 years ago
Yes, let's do that.  Brian, any chance you could revive that out of your patch in attachment 619045 [details] [diff] [review]?
Summary: cmd_copyImage changed/reverted functionality → Add cmd_copyImageContentsAndHTML
so you want a new command that has new functionality and leave the current command with the current functionality? or you want to revert the old command to do what it did and add a new command which is used from the menu?
I'm a bit confused because cmd_copyImage currently does HTML and image data. But I thought we wanted a new command cmd_copyImageAll to have image data HTML and text.

But you just labeled the title of the bug to be "Add cmd_copyImageContentsAndHTML" which is what cmd_copyImage already does.
Note that SeaMonkey worked around the bug with the following code:
function CopyImage()
{
  var param = Components.classes["@mozilla.org/embedcomp/command-params;1"]
                        .createInstance(Components.interfaces.nsICommandParams);
  param.setLongValue("imageCopy",
                     Components.interfaces.nsIContentViewerEdit.COPY_IMAGE_ALL);
  document.commandDispatcher.getControllerForCommand("cmd_copyImage")
          .QueryInterface(Components.interfaces.nsICommandController)
          .doCommandWithParams("cmd_copyImage", param);
}
that sounds like a good enough solution to me, can we close this out in that case?

Comment 15

6 years ago
(In reply to comment #12)
> I'm a bit confused because cmd_copyImage currently does HTML and image data.
> But I thought we wanted a new command cmd_copyImageAll to have image data HTML
> and text.

Yeah sorry, that's what I mean.

Comment 16

6 years ago
(In reply to comment #14)
> that sounds like a good enough solution to me, can we close this out in that
> case?

If that's acceptable to OMR, it sounds good to me.
(Reporter)

Comment 17

6 years ago
Sounds good. Thanks. (and for the work-around code)

Comment 18

6 years ago
Thanks a lot for your cooperation, OMR!  I'll mark this as WONTFIX as we decided to not change anything on our side.  If you hit issues, please comment here or reopen the bug.  Thanks!
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.