19428 - [DOGFOOD] Copy/paste from Messenger View Pane to Edit field/area be made functional

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Message Display, defect, P3)

Description

[Katsuhiko Momoi]

** Observed with 11/19/99 Win32 M12 build **

Currently, we are not able to copy data  from a received message into any of the Editable
text fields/areas. I looked through the bug data base but could not find a bug which addresses this problem.
If there is one filed somewhere, pleas emark this a duplicate.

I'm marking this [Dogfood] because in international testing we deal with data we cannot
input easily with keyboards. For daily use, it is necessary that we can copy from Message window
into Editable fields for a variety of tasks. Not having this function has hampered our work.

Comment 1

[leger]

Putting on the PDT+ radar.

Comment 2

[hangas]

What we need here is a "controller" written in either JS or C++ that is attached
to the message pane.  It will be able to handle the Copy and Select All
functions.  I suspect that this is being written by Radha or Buster for the html
content in the browser, and we could just use what they develop.

Comment 3

[Phil Peterson]

Radha or Steve?

Comment 4

[Phil Peterson]

Paul, this seems similar to bug 14026 and bug 12022

Comment 5

[hangas]

Sending to buster.  I believe that the ability to copy text from a content frame
and paste in an html:input field are features that buster is working on.  The
command updating and dispatching code is in place in this window, we just need
the appropriate controllers attached to the widgets.

Comment 6

[rubydoo123]

removing fix by date, Steve needs to review/evaluate before we set a date

Comment 7

[rubydoo123]

linking to 12658, composer pdt+ bug tracking

Comment 8

[buster]

ok, my portion of this bug is fixed.  you can now copy/paste to/from html text
controls.  the browser folks are responsible for creating a controller for
normal html content.  So I think the remainder of this bug is a dup of 12022.
assigning to davidm to let him decide if it's really a dup or not.

Comment 9

[don]

David, is this a dupe?

Comment 10

[davidm]

It's the same work but I don't think it's a dup.

Comment 11

[davidm]

Move off to m13 since some webshell work needs to be done.

Comment 12

[davidm]

move back to m12 since it now turns out the work is being done in a place that
will fix both bugs. This is now most likely a dup of 19428.

Comment 13

[davidm]

copy is working in my linux messenger build.

Comment 14

[Katsuhiko Momoi]

Though it is a Mozilla build (1999121320), tonight's Windows
build shows that copy is working from Messenger view pane also.
We should be able to do full verification with tomorrow's build.

Comment 15

[Katsuhiko Momoi]

Assigning myself as QA contact -- we need to check this with
several different language data.

Comment 16

[ji]

It works fine on Linux 1999121320 build with Japanese data.

Comment 17

[Katsuhiko Momoi]

Copy/paste is working on 12/14/99 Win32 and MacOS builds.
I was able to copy from Messenger message viewing pane to:

1. All Mail Compose window widgets.
2. Editor field
3. Navigator localtion field
4. Navigator form field/area
5. Address Book widgets

Edit | Copy menu is also enabled now.

Marking the fix verified.

Comment 18

[Katsuhiko Momoi]

We are seeing this problem again!! with 2/17/2000 Win32 build,
and apparently with Linux build also.

Comment 19

[davidm]

Is this working in the browser? Reassign to XPToolkit since this is likley to be 
a focus/command handling bug. If it isn't reassign to don.

Comment 20

[Katsuhiko Momoi]

It is working from Browser window to an edit field.
This problem is restricted to the copying from Mail viewing window
to edit fields.
The menu is disabled and CTRL+C does not work at all.
This was working at M13.

Comment 21

[Peter Trudelle]

This is limited to copying from message pane, period, and only on Windows & Mac.
Even on these platforms, paste works in these places, it is the copy that fails.
On Linux, it is working fine in cases 1-4 above. I couldn't test case 5 because
I couldn't get a new address book card, or open one for editing.
changing target from M12 to M14, reassigning to sfraser

Comment 22

[Simon Fraser [no longer active]]

This diff will fix that. Review, please, hangas?

Index: messenger.xul
===================================================================
RCS file: /cvsroot/mozilla/mailnews/base/resources/content/messenger.xul,v
retrieving revision 1.130
diff -c -2 -r1.130 messenger.xul
*** messenger.xul	2000/02/15 21:38:45	1.130
--- messenger.xul	2000/02/18 01:29:46
***************
*** 63,66 ****
--- 63,68 ----
  
  	<commandset id="globalEditMenuItems"/>
+ 	<commandset id="selectEditMenuItems"/>
+ 	<commandset id="undoEditMenuItems"/>
  </commands>
  

Comment 23

[Simon Fraser [no longer active]]

Fix checked in.

Comment 24

[Katsuhiko Momoi]

** Checked with 2/21/2000 Win32 build **

Now I can copy from the Message viewing window at least 
and paste into HTML edit field such as HTML Composer and HTML
Mail composer message area.
But I am not able to paste into any text edit field such as
Plain Text message compose area, Nav Location field, browser form,
Mail Subject and headers, Adrress Book new Card window fields, etc.

I'm going to re-open this bug for the paste problem into these
text edit fields.

Comment 25

[Akkana Peck]

Agreed -- I see this problem too.  I'll take a look, since it looks similar to
another problem I was looking at last week.

Comment 26

[Akkana Peck]

The problem turns out to be that the parser calls OpenContainer on tag 118
(eHTMLTag_markupDecl, i.e. the doctype), then calls OpenContainer on tag 119
(eHTMLTag_userdefined), then calls CloseContainer on the doctype tag without
ever calling CloseContainer on the userdefined tag.  I don't understand where
the userdefined tag is coming from or why it's never closed.  But I have a fix,
which is to alter the code in CloseContainer to search back for the last
matching tag, and pop the stack to that point only if we see a matching tag.
Will attach to this bug and seek review.

Comment 27

[Akkana Peck]

Attachment: Patch to work around the parser doctype problem

Comment 28

[buster]

sounds like one of the parser boys will have to review this.  cc'd rickg and 
harishd.

Comment 29

[Akkana Peck]

*** Bug 28447 has been marked as a duplicate of this bug. ***

Comment 30

[sairuh (rarely reading bugmail)]

spam: added self to cc list, as this affects my areas. and after reading through
the trail of verifs/dups... basically, cannot paste into dialogs (eg, Open
Location, Find) using Ctrl/Command+V --only on mac and winNT. but let me know if
i should open a separate bug on what i'm seeing.

Comment 31

[Akkana Peck]

Harish found a much better fix.  Basically, there's no reason either of us can
see why the document_info tag is being pushed onto the stack inside nsXIFDTD,
and removing that cures the problems and also fixes a longstanding nagging issue
with the automated tests (the extra newline at the beginning of xifstuff.out
which shouldn't have needed to be there).  I will attach Harish's patch to the
bug.  We're hoping to check this in tomorrow (along with the updated xifstuff
test), assuming no one has any objections.

Comment 32

[Akkana Peck]

Attachment: Harish's better patch

Comment 33

[harishd]

Attachment: Yet another patch..

Comment 34

[Akkana Peck]

Checked in.

Comment 35

[Katsuhiko Momoi]

** Checked with 2/23/2000 Win32 build **

This is working great with the above build. Now I can copy from
Message viewing window to any editable field, e.g. Mail headers,
Mail text body,Address Book Card field, etc.

I found that there are a few places we cannot paste into. They are
Search dilog (Find) window keyword field and Bookmark properties.
There might be others like these 2. But You can't paste into these
edit fields from Browser window, either. Looks like a general
problem we need to deal with in another bug.

If anyone knows of an existing bug on this remaining problem,
let me know.

ji, please see if this fix is working on today's Linux build.
cwang, please look at this on today's Mac build.
When I hear from others about other platforms and also from
someone about the problem in Find and Bookmark properties fields,
I'll mark this fix verified.

Comment 36

[Akkana Peck]

You might want to look at bug 28680, "can't paste into form text controls",
though it was recently marked fixed.

Comment 37

[ji]

Check with today's linux build. Same behaviour as windows build.

Comment 38

[Charles Wang]

Today's Mozilla bits build for MAC is the same as Window Build.
-Charles

Comment 39

[Katsuhiko Momoi]

Thank you, akkana, ji, and cwang. 
Given the reports from ji and cwang, the current
fix is now verified on all 3 platforms. 
The remaining problem is addressed in Bug 28680 apparently
though the fix there does not seem to work with today's build
as reported above for all 3 platforms.

elig, do you now the current status of Bug 28680?

Marking the current fix verified.

Comment 40

[bijals (gone)]

There still seems to be a problem with pasting.  When I pasted the top 5 lines 
from a bug notification email message from the Mail read pane, the pasted text 
did not include carriage returns/breaks that existed in the original text 
copied.

Comment 41

[Katsuhiko Momoi]

akkana, bijals is right.
We don't preserve any lin breaks of the original.
Is this something to be handled in this bug? If so, let's
re-open this bug.

Comment 42

[Akkana Peck]

No, that's a completely different issue, and should be filed as a separate bug
(to me).