Last Comment Bug 330868 - Paste Disabled After Copy from a Source That Is Not a Thunderbird Compose Window
: Paste Disabled After Copy from a Source That Is Not a Thunderbird Compose Window
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Editor (show other bugs)
: unspecified
: x86 Other
: -- normal with 4 votes (vote)
: mozilla16
Assigned To: :Ehsan Akhgari
:
: Makoto Kato [:m_kato]
Mentors:
: 332368 379586 (view as bug list)
Depends on:
Blocks: 606728 719413
  Show dependency treegraph
 
Reported: 2006-03-17 12:49 PST by David E. Ross
Modified: 2012-07-04 06:37 PDT (History)
19 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Patch (v1) (3.13 KB, patch)
2011-10-06 13:04 PDT, :Ehsan Akhgari
no flags Details | Diff | Splinter Review
Patch (v2) (2.20 KB, patch)
2012-07-03 15:30 PDT, :Ehsan Akhgari
roc: review+
Details | Diff | Splinter Review

Description David E. Ross 2006-03-17 12:49:22 PST
User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.0.1) Gecko/20060130 SeaMonkey/1.0 Mnenhy/0.7.3.0
Build Identifier: Thunderbird 1.5 (20051201)

If I copy text from a non-Thunderbird window to paste into the Thunderbird composition window, the Paste option in the right-click pull-down menu is sometimes disabled.  The Paste as Quote option is still enabled.  

Reproducible: Sometimes

Steps to Reproduce:
1.  Mark and copy a block of text from a SeaMonkey window.  
2.  Use right-click in a Thunderbird compose window to get the pull-down menu.  


Actual Results:  
The Paste option is disabled (gray).  

Expected Results:  
The Paste option should be enabled (black).  

Ctrl-V (keyboard shortcut for Paste) still works.  This problem seems to occur more frequently if I have already entered some text into the compose window and if the copied text has a link behind it.
Comment 1 David E. Ross 2006-03-18 10:06:12 PST
One frequent situation in which this problem is seen is when I am replying to a message in a news.mozilla.org newsgroup.  If I want to cite a bug report in my reply, I use SeaMonkey to login to Bugzilla and run one of my preset queries.  In the Bug List, I select the bug number (a link) and use [right-click: Copy] (not Copy Link Location).  Then, in the Thunderbird compose window, I go to paste the bug number.  Often (not always), [right-click: Paste] and [Edit > Paste] are both disabled.  Instead, I have to use CTRL-v to paste.  

Usually, I also include a link to the bug in my reply.  Today, I noticed that, after [right-click:Copy Link Location], both [right-click: Paste] and [Edit > Paste] were both disabled for that, too.  
Comment 2 Russell Howe 2006-04-03 08:32:30 PDT
I can confirm this (or rather, some of our users can) using Thunderbird version 1.5 (20051201) on Windows 2000 via Citrix.

It also happens when copying text from a Thunderbird message window and
subsequently trying to paste it into a composition window (using the right mouse
button).

Minimising the composition window and restoring reportedly sometimes (but not
always) restores the paste option.
Comment 3 Tracy boyd 2006-06-05 11:25:45 PDT
I cannot paste any text into a message if the text came from a website. The items I find I CAN paste is if they were entered in an online text field (copy the text directly from the field and paste it into the email text area). 

Whereas, after I submit the form and it gets posted on the page, if I copy the very text I just entered, it will not copy into the main text area  (although it will copy into the Subject or Address fields).

All text copied from Word or similar applications seems to copy just fine.

Tracy Boyd

Comment 4 Russell Howe 2006-06-09 02:45:40 PDT
(In reply to comment #3)
> I cannot paste any text into a message if the text came from a website.

With all due respect, as far as Thunderbird's concerned, the text is coming
from an application (or the Windows clipboard).

What application are you using to view the website whose text you are trying to
copy?

Mozilla Firefox?
Internet Explorer?
OS X Safari?
Konqueror?
Comment 5 allthatstuff 2006-07-15 04:22:03 PDT
Firefox 1.5.0.4, Camino 1.0.2, and Thunderbird 1.5.0.4 on Mac OSX 10.4.7

If I try to paste a HTML-formated String (so, e.g. copy=pasting from a input textbox does work) from Camino or Firefox into Thunderbird, it will only work if I paste with the "Paste without formatting" function (i.e. also CTRL-V does not work). If I try to paste plain text messages, it is no problem. (so, e.g. copy a string for Firefox, paste to Emacs, copy again and paste to Thunderbird works). Rather annoying bug...

Interestingly, pasting from Safari does work (although the formatting is lost on the way anyway), while pasting from Camino or Firefox does not work...

Hope this helps!
Comment 6 Ryan Grange 2006-08-04 12:20:35 PDT
We're seeing this in our office as well.  Copying is being done from IE and Firefox (both on XP Pro) and upon bringing up a compose window, paste isn't available immediately.  Switching to another window and back again enables paste.  Not sure if Ctrl-V is operational or not at this point.  Will update bug when I know for sure.
Comment 7 Mike Cowperthwaite 2006-09-04 11:55:17 PDT
*** Bug 332368 has been marked as a duplicate of this bug. ***
Comment 8 Sven Dack 2006-12-21 02:51:30 PST
In addition to the above comments:

- The bug is independent from where the text has been copied.
- If one does cut/copy/paste inside the compose window a second attempt to paste text from outside then succeeds.
- It only occurs once while Thunderbird is running and cut/copy/paste has been used successfully with the compose window.

Initialisation problem?
Comment 9 Tony Mechelynck [:tonymec] 2006-12-23 07:48:35 PST
Don't know if this is the same bug, but sometimes (especially when system load is high), pasting _from_ Thunderbird 2.0b1 "View Source" window _to_ a textarea in Seamonkey 1.5a doesn't work either (Right-click => Paste is greyed out); but pasting from Tb into gvim followed by pasting from gvim into Sm always works.

Currently using:
- "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.2pre) Gecko/20061223 Thunderbird/2.0b1" - Build ID: 2006122304
- "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a2pre) Gecko/20061223 SeaMonkey/1.5a" - Build ID: 2006122301
- SuSE Linux 9.3, `uname -a` == "Linux linux 2.6.11.4-21.15-default #1 Tue Nov 28 13:39:58 UTC 2006 i686 athlon i386 GNU/Linux"
Comment 10 Martin Butter 2007-02-20 01:26:20 PST
On de.comm.software.mozilla.mailnews I found another workaround for this bug for people who don't like to use Ctrl-V: After one click on the "from"-field - so that a list of possible senders appears - and another click in the text, the paste-option on right-click reappears. This works for me (with Thunderbird 1.5.0.9 DE on Win XP).

Comment 11 David E. Ross 2007-04-09 17:32:40 PDT
Today, I observed this problem when I copied ASCII text from a newsgroup message and attempted to paste that text into a new message for the same newsgroup.  In this case, I was copying from one TBird window to paste into another TBird window, all in the same TBird instance.  
Comment 12 Magnus Melin 2007-05-05 09:15:52 PDT
*** Bug 379586 has been marked as a duplicate of this bug. ***
Comment 13 David E. Ross 2011-02-21 12:49:24 PST
The population of annoyed users -- annoyed because this bug has not yet been fixed -- is growing.  Periodically, this annoyance results in a lengthy thread in the mozilla.support.thunderbird newsgroup.  

Changing severity from Minor.
Comment 14 Mark Banner (:standard8, afk until Dec) 2011-02-21 12:59:55 PST
Having just tried a few things over the last few minutes, I can't reproduce it at all.

What this bug really needs is some detailed steps to repeat, or at least an indication of the most likely scenarios where it is to occur. Without those it is likely to be very difficult to figure out what is going wrong here.

For example:

- Is it the first time you open up the compose window?
- Or a subsequent time?
- Is it a particularly large piece of text, or maybe special characters?
- Does anything appear on the error console?
Comment 15 David E. Ross 2011-02-21 13:21:58 PST
Please see the thread "Can't Paste (only "Paste as Quote")" in newsgroup mozilla.support.thunderbird.  My reply describes having this problem just 20 minutes ago.  

A test case is not easy to construct because the bug is intermittent: "Reproducible: Sometimes".  I just now tried to repeat what happened when I composed my reply.  I could not recreate the problem.  However, I see this problem several times each week.  

If I can determine steps that will frequently -- but not consistently -- show the problem, I will post those steps here.
Comment 16 Ed 2011-03-26 03:10:45 PDT
It still happens in SeaMonkey 2.0.14pre as it did in previous versions.
Sometimes 'PASTE' is grayed out and only 'Paste as Quote' is available.

I also cannot cause or determine any rhyme or reason to this.
Comment 17 Wayne Mery (:wsmwk, NI for questions) 2011-04-13 05:13:26 PDT
Adding to comment 14, it would help for a reporter to test this against current (trunk) development builds. Even though this is intermittent, given it's frequency (comment 15) it sounds like this should not be hard to do.
Comment 18 David E. Ross 2011-07-10 06:54:52 PDT
Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0

This is still a problem, but it is still intermittent.
Comment 19 Rich 2011-08-18 06:44:03 PDT
I can reproduce it easily in Thunderbird 5 on Ubuntu 11.04, xclip 0.12

$ echo hello | xclip -selection clipboard

Now try to paste into the compose window: nothing.
Paste into the subject line: works fine.

Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10
Comment 20 Ludovic Hirlimann [:Usul] 2011-09-07 05:18:35 PDT
(In reply to Rich from comment #19)
> I can reproduce it easily in Thunderbird 5 on Ubuntu 11.04, xclip 0.12
> 
> $ echo hello | xclip -selection clipboard
> 
> Now try to paste into the compose window: nothing.
> Paste into the subject line: works fine.

can you paste it using Ff at http://www.mozilla.org/editor/midasdemo/ ?
Comment 21 Rich 2011-09-07 14:23:28 PDT
(In reply to Ludovic Hirlimann [:Usul] from comment #20)
> can you paste it using Ff at http://www.mozilla.org/editor/midasdemo/ ?

No I cannot. (And I added the user.js prefs file, too.)
Comment 22 :Ehsan Akhgari 2011-10-06 13:04:05 PDT
Created attachment 565329 [details] [diff] [review]
Patch (v1)

So, this can happen when the widget lies to us about the data being CF_HTML.  Here, we need to handle the case where ParseCFHTML fails, and we need to treat the string as a normal HTML snippet.
Comment 23 David E. Ross 2011-10-06 13:24:21 PDT
Note well:  This problem occasionally happens when attempting to copy from a Thunderbird message window into a Thunderbird compose window.  I have updated the Summary accordingly.
Comment 24 jay garcia 2011-10-23 07:53:19 PDT
I am unable to reproduce this with TB 7.0.1 and Seamonkey 2.1.4 and using Firefox 7.0.1 to copy the text.

OS's used are XP-SP3 and Win-7
Comment 25 David E. Ross 2011-10-23 14:33:55 PDT
Windows XP Home Edition Version 5.1 (Service Pack 3)
Mozilla/5.0 (Windows NT 5.1; rv:7.0) Gecko/20110922 Thunderbird/7.0

I observed this problem after installing 7.0.  Unless something else was fixed with 7.0.1 other than the advertised Add-ons Manager problem, it should still exist in 7.0.1.  

The fact that some users have not seen this problem does not mean it does not exist.  This is a transient problem.  I have been unable to create this problem purposely despite many, many attempts; but I encounter it when I do not expect it.
Comment 26 Andy Civil 2011-10-25 08:47:03 PDT
This bug is caused by the status of the "Paste" command not being updated to reflect the presence or absence of text on the clipboard. To demonstrate (replicate) this bug, clear your clipboard (use the clipbrd application on Windows, or the xsel command on Linux) and open a compose window. Switch focus to the body; you can verify that both "paste" commands are greyed out. Now put some text on the clipboard by copying something. Switch back to the compose window, but take care to keep focus on the body pane, otherwise the bug will not manifest. Right click, and the context menu is wrong, because the "Paste" command is still greyed out, it did not update to reflect the data on the clipboard. Changing focus to the subject line, or any other part of the compose window, and then back to the body pane, will cause the "Paste" command to update and become valid. This bug has been present since version 2.0.0.0. on Windows, and is also present on Linux.

One possible fix for this bug is to edit, within the messenger.jar file, chrome\content\messenger\messengercompose\MsgComposeCommands.js and add a command to the function updateEditItems() to goUpdateCommand("cmd_paste") which solves the problem, at least on my system.

I have uploaded a video demonstrating this to Youtube at http://www.youtube.com/watch?v=Z3WBQ-SRxnE

This bug has been very hard to replicate (over five years old now) because most people do not clear their clipboard as part of normal use. Thus anyone who tries to find the bug by deliberate effort will never see it, but the user who turns their computer off at night will experience it again when they boot up in the morning.
Comment 27 jay garcia 2011-10-25 09:44:05 PDT
Following your method to reproduce this I can concur, it happens here like you said. However, the "paste as quotation" is available and works. For those of us that have maintained that the paste option is not grayed out is because we copy text first, prior to opening a compose window.
Comment 28 :Ehsan Akhgari 2012-01-18 14:34:55 PST
(In reply to Andy Civil from comment #26)
> This bug is caused by the status of the "Paste" command not being updated to
> reflect the presence or absence of text on the clipboard. To demonstrate
> (replicate) this bug, clear your clipboard (use the clipbrd application on
> Windows, or the xsel command on Linux) and open a compose window. Switch
> focus to the body; you can verify that both "paste" commands are greyed out.
> Now put some text on the clipboard by copying something. Switch back to the
> compose window, but take care to keep focus on the body pane, otherwise the
> bug will not manifest. Right click, and the context menu is wrong, because
> the "Paste" command is still greyed out, it did not update to reflect the
> data on the clipboard. Changing focus to the subject line, or any other part
> of the compose window, and then back to the body pane, will cause the
> "Paste" command to update and become valid. This bug has been present since
> version 2.0.0.0. on Windows, and is also present on Linux.
> 
> One possible fix for this bug is to edit, within the messenger.jar file,
> chrome\content\messenger\messengercompose\MsgComposeCommands.js and add a
> command to the function updateEditItems() to goUpdateCommand("cmd_paste")
> which solves the problem, at least on my system.
> 
> I have uploaded a video demonstrating this to Youtube at
> http://www.youtube.com/watch?v=Z3WBQ-SRxnE
> 
> This bug has been very hard to replicate (over five years old now) because
> most people do not clear their clipboard as part of normal use. Thus anyone
> who tries to find the bug by deliberate effort will never see it, but the
> user who turns their computer off at night will experience it again when
> they boot up in the morning.

Hi Andy,

Thanks for the great analysis here.  What you're describing is indeed a bug, but a different bug than this one.  This bug is caused because Linux lies to us about the type of data available on the clipboard.  The bug that you have found is caused by us not updating the menu items at the right time.

I suggest that you file a separate bug and attach a patch to that bug and ask Blake (bwinton) for review.

roc: what happened to this patch?  Was it lost in your review queue?  I had totally lost track of this bug.  :(
Comment 29 David E. Ross 2012-01-18 17:20:09 PST
Re comment #28:

As the originator of this bug report, I can tell you that this is NOT a Linux-specific bug.  I don't use Linux.  I reported this when I was still using Windows 98.  I still see it with Windows XP SP3.  

Since I see this with Windows and you see it with Linux, I have changed the OS to "All".
Comment 30 Andy Civil 2012-01-18 22:17:38 PST
I think what's happening here is that there is more than one bug. Martin Butter in comment 10 is clearly describing the same bug that I found a fix for. However, Rich in comment 19 is clearly describing the bug that Ehsan found a fix for.

So how does one define what "this bug" is? I'm sure David feels able to claim that the bug is 'his' since he created the report and has pushed for a solution.

However, Rich was the first to deliver a method of consistently replicating "this bug" [sic] so obviously, that is what Ehsan focused on, and what he found a solution to.
Comment 31 :Irving Reid (No longer working on Firefox) 2012-01-19 05:55:50 PST
(In reply to Andy Civil from comment #30)
...
> So how does one define what "this bug" is? I'm sure David feels able to
> claim that the bug is 'his' since he created the report and has pushed for a
> solution.

We don't need to get too fussed about which bug is which, as long as they both get fixed. I'll clone this bug and assign the clone to Andy, and make sure that David is copied on the clone.
Comment 32 Tony Mechelynck [:tonymec] 2012-06-16 07:54:55 PDT
I've started bug 765491, porting bug 719413 to SeaMonkey.
Comment 33 :Ehsan Akhgari 2012-06-18 12:40:57 PDT
roc: ping?  :)
Comment 34 Robert O'Callahan (:roc) (email my personal email if necessary) 2012-06-20 17:36:56 PDT
Comment on attachment 565329 [details] [diff] [review]
Patch (v1)

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

::: editor/libeditor/html/nsHTMLDataTransfer.cpp
@@ +1416,5 @@
> +        if (textDataObj && len > 0) {
> +          nsCAutoString text;
> +          textDataObj->GetData(text);
> +          NS_ASSERTION(text.Length() <= len, "Invalid length!");
> +          stuffToPaste.AssignASCII(text.get(), len);

Should this be treated as UTF-8 instead?
Comment 35 :Ehsan Akhgari 2012-06-29 15:57:19 PDT
AssignASCII is actually a synonym for Assign for nsCStrings...  But I just realized that this patch is heavily bitrotten.  I'll submit a new patch when I test this again, since it's been a while since I wrote this and I want to make sure that the patch is still valid.
Comment 36 :Ehsan Akhgari 2012-07-03 15:30:02 PDT
Created attachment 638889 [details] [diff] [review]
Patch (v2)

You were right.  This version of the patch correctly deals with UTF8 data.
Comment 38 Ryan VanderMeulen [:RyanVM] 2012-07-04 06:37:37 PDT
https://hg.mozilla.org/mozilla-central/rev/de483b66eb94

Note You need to log in before you can comment on or make changes to this bug.