Paste Disabled After Copy from a Source That Is Not a Thunderbird Compose Window

RESOLVED FIXED in mozilla16

Status

()

Core
Editor
RESOLVED FIXED
11 years ago
5 years ago

People

(Reporter: David E. Ross, Assigned: Ehsan)

Tracking

unspecified
mozilla16
x86
Other
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

11 years ago
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.
(Reporter)

Comment 1

11 years ago
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

11 years ago
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

11 years ago
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

11 years ago
(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

11 years ago
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

11 years ago
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

11 years ago
*** Bug 332368 has been marked as a duplicate of this bug. ***

Comment 8

11 years ago
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?
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

10 years ago
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).

(Reporter)

Comment 11

10 years ago
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.  
QA Contact: message-compose

Updated

10 years ago
Duplicate of this bug: 379586

Updated

9 years ago
Assignee: mscott → nobody
(Reporter)

Comment 13

6 years ago
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.
Severity: minor → normal
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?
Keywords: testcase-wanted
(Reporter)

Comment 15

6 years ago
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

6 years ago
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.
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.
(Reporter)

Comment 18

6 years ago
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

6 years ago
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
(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

6 years ago
(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.)
Component: Message Compose Window → Editor
Product: Thunderbird → Core
QA Contact: message-compose → editor
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.
Assignee: nobody → ehsan
Status: NEW → ASSIGNED
Attachment #565329 - Flags: review?(roc)
(Reporter)

Comment 23

6 years ago
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.
Summary: Paste Disabled After Copy from Non-Thunderbird → Paste Disabled After Copy from a Source That Is Not a Thunderbird Compose Window

Updated

6 years ago
Blocks: 606728

Comment 24

6 years ago
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
(Reporter)

Comment 25

6 years ago
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

6 years ago
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

6 years ago
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.
(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.  :(
(Reporter)

Comment 29

5 years ago
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".
OS: Other → All

Comment 30

5 years ago
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.
(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.
OS: All → Other
Blocks: 719413
I've started bug 765491, porting bug 719413 to SeaMonkey.
roc: ping?  :)
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?
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.
Created attachment 638889 [details] [diff] [review]
Patch (v2)

You were right.  This version of the patch correctly deals with UTF8 data.
Attachment #565329 - Attachment is obsolete: true
Attachment #565329 - Flags: review?(roc)
Attachment #638889 - Flags: review?(roc)
Attachment #638889 - Flags: review?(roc) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/de483b66eb94
Target Milestone: --- → mozilla16
Keywords: testcase-wanted
https://hg.mozilla.org/mozilla-central/rev/de483b66eb94
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.