Closed
Bug 286118
Opened 19 years ago
Closed 15 years ago
"Copy Image" should only copy image data (not URL) due to incompatability with Windows apps
Categories
(Firefox :: Menus, defect)
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...
Comment 1•19 years ago
|
||
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
Reporter | ||
Comment 2•19 years ago
|
||
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
Updated•19 years ago
|
Assignee: firefox → nobody
QA Contact: bugzilla → menus
Version: Trunk → unspecified
Comment 3•19 years ago
|
||
(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
Comment 4•15 years ago
|
||
That looks like a dupe of bug 291619. Reporter can you please verify?
Updated•15 years ago
|
Whiteboard: [closeme 2009-07-31]
Comment 5•15 years ago
|
||
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.
Comment 6•15 years ago
|
||
Thanks for your prompt feedback! Good to hear. That manifests my assumption that it is a dupe. Marking so.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
Comment 7•15 years ago
|
||
Oh, I mixed up the persons. Kevin, if you can see it feel free to reopen.
Comment 8•15 years ago
|
||
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.
Description
•