448326 - Paste/Copy/Cut not working from menus when composing message

Status: RESOLVED FIXED

(Thunderbird :: Message Compose Window, defect, P1)

Description

[Willie Reid]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a2pre) Gecko/2008072803 Firefox/3.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a2pre) Gecko/2008072800 Shredder/3.0a2pre ID:2008072800

When composing a new message the Edit > Paste (and RMC > Paste) sequence in the text pane produces no results. CTRL+V works fine. Edit (or RMC) > "Paste as quotation" / "Paste without formatting" also work fine.

Reproducible: Always

Steps to Reproduce:
1. Copy text from any source
2. Open Write to compose new message
3. In text pane, use Edit > paste.
Actual Results:  
Nothing is pasted in text pane

Expected Results:  
Text should have been pasted

Comment 1

[Willie Reid]

Please note.
Bug #330868 from 2 years ago has similar behaviours but is not identical as far as I can see.

Comment 2

[rsx11m]

Edit > Paste works for Thunderbird/3.0a2 (Windows; 2008072418)
does not work for Thunderbird/3.0a2pre (Windows; 2008072500)

Both observed in plain-text and HTML composition modes. The "Paste" menu item is not greyed out. Possibly related to 1.9.0/1.9.1 switch to comm-central.

Not a core bug though, Edit > Paste works normally in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a2pre) Gecko/2008072800 SeaMonkey/2.0a1pre for Mail/News and Composer, thus the backend appears to be working.

No duplicate found, confirming.

Comment 3

[Marcel Kneuer]

For me also rightclicking and using "paste" doesn't work. Pasting with "ctrl-V" works. "Paste as quotation" works in every situation. 

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a2pre) Gecko/2008073000 Shredder/3.0a2pre ID:2008073000

Comment 4

[Kirk M]

Additional anomalies that I've found that probably pertain to this error as well (reprinted from the my forum post). My tests show it's just not the paste option but copy and cut as well but only when accessed through a menu as described below.

"I've noticed that attempting to use the right click menu (Windows XP pro SP3) for "Cut, Copy or Paste" does not work at all as well as using these same commands via the File/Edit drop down menu. However, "Paste Without Formatting" and "Paste As Quotation" do work okay when accessed in either menu. Also, the keyboard shortcuts for all these functions work normally."

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a2pre) Gecko/2008080500 Shredder/3.0b1pre ID:2008080500

Comment 5

[Kirk M]

Please ignore the OS reference in above comment. Meant to take that out.

Comment 6

[Willie Reid]

Yes, agree with comment #4 RMB + Copy or Cut are not working for me either.

Comment 7

[rsx11m]

Also seen on Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1a2pre) Gecko/2008080700 Shredder/3.0b1pre, thus not platform dependent. The menu items are correctly showing active or grayed out, but are not functional.

Adjusting platform flags, and the summary per comment #4. 

Comment 8

[rsx11m]

For someone not using (or not being aware of) the keyboard shortcuts for Copy/Cut/Paste, this may be a substantial usability issue.

This bug is quite visible and should be fixed for 3.0b1, for sure with
the 3.0 release, thus nominating. 

Comment 9

[David :Bienvenu]

paste as quotation and paste w/o formatting both work; just normal paste doesn't.

Comment 10

[David :Bienvenu]

I'll look into this

Comment 11

[Marcel Kneuer]

I also found out, that Edit > Undo doesn't work while ctrl-z works.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a2pre) Gecko/20080815074052 Shredder/3.0b1pre ID:20080815074052

Comment 12

[Kirk M]

(In reply to comment #11)
> I also found out, that Edit > Undo doesn't work while ctrl-z works.
> 
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a2pre)
> Gecko/20080815074052 Shredder/3.0b1pre ID:20080815074052
> 

Confirmed. Neither does "Edit > Select All" but only when composing. "Edit > Select All" in TB's main window functions correctly and highlights all text showing in the preview pane.

Dave, should this be a blocker for beta 1?

Comment 13

[David :Bienvenu]

I did mark it as a beta 1 blocker.

Comment 14

[Kirk M]

Oops, I missed the +. Sorry about that.

Comment 15

[David :Bienvenu]

putting in b1 milestone

Comment 16

[David Ascher (:davida)]

Switching for b1 flags to target milestones, to avoid flag churn.

Comment 17

[David :Bienvenu]

We're not getting to nsBaseCommandController::DoCommand, so the problem is most likely in the xul. It would be interesting to know if SeaMonkey has the same issue.

Comment 18

[rsx11m]

I was unable to reproduce this on the corresponding SeaMonkey comm-central builds when confirming, thus specific to Thunderbird:

> (comment #2) Edit > Paste works normally in Mozilla/5.0 (Windows; U;
> Windows NT 5.1; en-US; rv:1.9.1a2pre) Gecko/2008072800 SeaMonkey/2.0a1pre for
> Mail/News and Composer, thus the backend appears to be working.

Comment 19

[David :Bienvenu]

Attachment: possible fix

this fixes the issue - I'm not sure why we need to do this now, however.

Comment 20

[David :Bienvenu]

Phil probably knows right off the top of his head why I needed to do this :-)

Comment 21

[Mark Banner (:standard8)]

Comment on attachment 335545 [details] [diff] [review]
possible fix

I'm not sure this is the correct fix. I'm not even sure if TB is at fault here.

I just tried removing the lines you changed, and all the functions popped into life.

What I can see is that composerEditMenuItems is defined in editorOverlay.xul, and the checked-in version sets cmd_undo etc with no attributes.

In messengercompose.xul, these commands are defined at composeCommands level (above composerEditMenuItems), with the oncommand attribute.

So it seems like the menu options are sometimes choosing the composerEditMenuItems commands instead of the top-level composeCommands versions.

As Phil said on irc, we're wrong to have two lots of identical ids defined in different places.

Comment 22

[[e-mail]]

Here's what SeaMonkey does for comparison: messengercompose.xul pulls in composerEditMenuItems from the "original" editorOverlay.xul, which pulls in cmd_undo from utilityOverlay.xul, which sets the oncommand attribute.

Comment 23

[David :Bienvenu]

Attachment: proposed fix

Removing these from editorOverlay.xul fixes the problem, as Standard8 pointed out. This leaves the commands in messengercompose.xul...

Comment 24

[[e-mail]]

Comment on attachment 335636 [details] [diff] [review]
proposed fix 

This doesn't need my review, although it does worry me that this change will make the editor commandupdater stop working properly.

It's interesting to note a big comment in messengercompose.xul (both versions) warning not to include cmd_pasteQuote, cmd_find or cmd_findNext, although even SeaMonkey's version includes cmd_delete and cmd_selectAll, which is probably a bug that Mnyromyr will want to fix.

Comment 25

[David :Bienvenu]

oops, sorry about the review request. The command updater seems to be working ok with the patch, in the sense that the edit menu commands are enabled/disabled appropriately based on selection and whats on the undo/redo queues.

Comment 26

[David :Bienvenu]

fix checked in