Closed Bug 286118 Opened 15 years ago Closed 11 years ago

"Copy Image" should only copy image data (not URL) due to incompatability with Windows apps

Categories

(Firefox :: Menus, defect)

x86
Windows XP
defect
Not set

Tracking

()

RESOLVED DUPLICATE of bug 291619

People

(Reporter: kevinar18, Unassigned)

Details

(Keywords: regression, Whiteboard: [closeme 2009-07-31])

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050311 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050311 Firefox/1.0+

As a understand it, Bug 135300 finished up the backend code for the "Copy Image"
feature.  This bug applies to which aspects of that code should be used on the
Windows platform.

Currently, "Copy Image" is setup to copy both text and image data.  On the
Windows platform, however, this copying of to types of data causes problems in a
number of applications.  Some applications will give priority to text over
images (requiring that the user go through extra steps to paste the image data).
 Other programs will only paste the text, and offer no means to paste the image
(I only know of 2 out of 12-17 different applications that are affected by this
issue.)  A summary of some programs that were tested are included below.

Reproducible: Always

Steps to Reproduce:
1. Using "Copy Image" in the context menu, copy an image on a website.
2. Go into various windows applications (that support pasting of both image and
text data) and paste the image.

Actual Results:  
Depending on the application, it will paste the image URL or the image itself.

Expected Results:  
It should always paste image data.  The reasons for this are varied.
1) "Copy Image" is expected to copy image data and only image data.  Very few,
if any, Windows applications copy both image and text data.  To copy both
detracts from common UI design and may confuse the user.  Note: Firefox's target
audience is less computer literate users.  To implement such an odd design for
the "Copy Image" feature will inevitably lead to useability problems for said users.
2) Many Windows applications give priority to text (over image data), thus
requiring extra steps to paste the requested image.
3) A few Windows applications do not have a "paste special" option, and will
paste the text instead of the image.  Thus, there is no way to paste the image
using the paste command.

Some users on Mozillazine helped test out a few applications (to see how they
reacted to the new "Copy Image" implementation.  The particular thread is
located here: http://forums.mozillazine.org/viewtopic.php?t=232611.
The following list of applications is a compilation of my own testing, as well
as testing by sproot and jonnyq on mozillazine's forums:

The following programs are unaffected.
They paste image data (using paste):
Fireworks MX 2004
Flash MX 2004 Pro
GIMP 2.2.4
MS Paint 5.1
OpenOffice.org 1.1.3
> presentation + drawing	
Paint Shop Pro 9
Photoshop


The following programs paste the URL (using standard paste):

Program  --  Can paste the image via other means?

Abiword 2.2.1  --  no
Christian Greeting Card Factory 1.0  --  no
MS Office Suite 2003
> Excel       --  Paste Special...
> PowerPoint  --  Paste Special...
> Publisher   --  Paste Special...
> VIsio       --  Paste Special...
> Word        --  Paste Special...
OpenOffice.org 1.1.3
> word processor  --  Paste Special...
> spreadsheet     --  Paste Special...
Wordpad  --  Paste Special...
Allow me to attempts to format the previous data in a readable format, and maybe
provide a standard format for others to report their results.

I believe the "expected action" is that if it's possible to paste the image,
that should happen first.  Text should be pasted by other means (paste special...)
If the current context ONLY allows text, then the text should be pasted
(text-only editors, such as notepad, the text tool in a graphics program, etc...)

Program                          Paste Image                  Paste Text
-------                          -----------                  ----------
Fireworks MX 2004		 Regular Paste                Pasting into a textbox using
the Text tool works 
Flash MX 2004 Pro		 Regular Paste                Paste Special has ASCII option
               
GIMP 2.2.4			 Regular Paste                ???
MS Paint 5.1			 Regular Paste		      Pasting into a textbox using the Text tool
works
OpenOffice.org 1.1.3
presentation + drawing		 Regular Paste	              ???
OpenOffice.org 1.1.3
> word processor		 Paste Special...             Regular Paste
> spreadsheet                    Paste Special...             Regular Paste
Paint Shop Pro 9		 Regular Paste		      ???
Photoshop			 Regular Paste                Pasting into a textbox using the Text
tool works 
Abiword 2.2.1			 no			      Regular Paste
Christian Greeting 
   Card Factory 1.0              no			      Regular Paste
MS Office Suite 2003
> Excel                          Paste Special...             Regular Paste
> PowerPoint			 Paste Special...             Regular Paste
> Publisher                      Paste Special...             Regular Paste
> VIsio                          Paste Special...             Regular Paste
> Word                           Paste Special...             Regular Paste
Wordpad                          Paste Special...             Regular Paste
Windows Messenger                (May work in "Whiteboard"?)  Regular Paste

My testing was done using the 20050310 nightly.  

BTW: I prefer the current behavior to the behavior in 1.0.1, which one major
exception: MS Word pastes the text, and the image must be pasted through "Paste
Special".  Fx 1.0.1 pastes the image and only the image via Ctrl+V.  (Other word
processors may show this same difference between 1.0.1 and the later nightlies.)
Summary: "Copy Image" not compatable with many Windows apps → "Copy Image" not compatible with many Windows apps
Version: unspecified → Trunk
Changing summary to reflect the actual purpose of this report, from:
"Copy Image" not compatible with many Windows apps
to:
"Copy Image" should only copy image data (not URL) due to incompatability with
Windows apps
based on Bug 210043 summary.

As mentioned in the previous post, the backend allows the choice of using just
the image date or the image data and URL.  Due to numerous problems that this
issue causes in Windows, it is recommended that we switch back to only copying
image data, and resolve the issue of reducing the number of items on the context
menu via other means.
Keywords: regression
Summary: "Copy Image" not compatible with many Windows apps → "Copy Image" should only copy image data (not URL) due to incompatability with Windows apps
Assignee: firefox → nobody
QA Contact: bugzilla → menus
Version: Trunk → unspecified
(In reply to comment #2)
...
> As mentioned in the previous post, the backend allows the choice of using just
> the image date or the image data and URL.  Due to numerous problems that this
> issue causes in Windows, it is recommended that we switch back to only copying
> image data, and resolve the issue of reducing the number of items on the context
> menu via other means.

Those "other means" could be an extension or based off an extension. Here is one
which might hold a clue:
http://forums.mozillazine.org/viewtopic.php?t=265893&highlight=image+toolbar

and
http://forums.mozillazine.org/
viewtopic.php?t=73324&highlight=image+toolbar
That looks like a dupe of bug 291619. Reporter can you please verify?
Whiteboard: [closeme 2009-07-31]
Trying with the release version of Fx 3.5.1, this does not seem to be a problem. When I do a "Copy Image" from the context menu on a Web page on Fx in Windows XP and try to paste it into any of the affected applications mentioned above, it works as expected: I get the image, not the URL. Office 2007 applications and Wordpad both worked for me.

Perhaps this behavior has changed in recent versions of Fx. (Has there always been both "Copy Image" and "Copy Image Location" in the context menu? Even if so, perhaps the former's behavior has changed since four years ago when this bug was reported.)

I recommend closing this bug (WFM?) unless the reporter or anyone else can verify its occurrence.
Thanks for your prompt feedback! Good to hear. That manifests my assumption that it is a dupe. Marking so.
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 291619
Oh, I mixed up the persons. Kevin, if you can see it feel free to reopen.
Yep, I'm not the reporter! But, in any case, I think closing this bug was appropriate. Bug 286118 has very few details, but it seems they may be referring to the same issue; if not, this bug is almost certainly a WFM, anyway.

Again, Kevin (or anyone), if this behavior is still present in recent versions of Firefox, feel free to reopen this bug.
You need to log in before you can comment on or make changes to this bug.