58807 - Copy/paste in tables includes cell

Status: VERIFIED DUPLICATE of bug 57292

(Core :: DOM: Editor, defect, P3)

Description

[Peter Trudelle]

Using this morning's MN6 candidate build on Win98.

Edit an HTML document containing a table.
Type some text into a cell.
Select some of the text.
Focus in another cell
Paste.
Expected: text is pasted.
Actual:   New, nested cell is pasted, with the text inside it.

Comment 1

[rubydoo123]

yes, if you select all of the content, then the content and the element gets
copied. That is by design, this will be readdressed in the go round, allowing
for a choice -- just the text or the text and its container(s).

*** This bug has been marked as a duplicate of 46459 ***

Comment 2

[sujay]

verified in 11/1 build.

Comment 3

[Peter Trudelle]

reopening. This is clearly a defect,whether it is in the design or
implementation.  It is not the same as offering new formatted/unformatted
options for copy/paste. I understand the concept, and know that it is used for
selecting e.g., all of a list item in popular products, although it should
really provide a way of selecting the bullet/cell/whatever to indicate that. I
have never once wanted to nest table cells, although I frequently copy their
contents around, so including the enclosing cell by default on copy/paste of the
contents makes Composer of no use to me for table editing. cc'ing some UI folks.

Comment 4

[rubydoo123]

the issue here is that we are looking at container objects, the td, tr and table
are container objects just like li and ul or ol. Allowing for a choice in future
release provide an option for the end user, however, at the present the current
implementaion will be used.

Remarking as a dup.

*** This bug has been marked as a duplicate of 46459 ***

Comment 5

[sujay]

verified in 11/5 build.

Comment 6

[Peter Trudelle]

You may be looking at containers, but the person using the editor is just
selecting text. Please reconsider this from a usability perspective.

Comment 7

[Peter Trudelle]

I really don't want to be a PITA, but I'm reopening this again. I just realized
it is also the cause of some problems that have been vexing me while editing my
progress reports.  When I copy text from bug listings and paste into a mail
message, an invisible table gets pasted in with it.  If I then select it all and
delete, the table remains, so the editor is not even being consistent about
which editing operations include the selection's container. Pasting visible
containers is one thing, but when they are not shown, it just appears defective.

Comment 8

[sujay]

Peter,

Beth is not marking your bug INVALID or WORKSFORME. 

I believe she is marking this bug a DUPLICATE. Which means
that this is a valid bug but is a duplicate of a bug that
is already filed.

Comment 9

[sujay]

Beth, perhaps we should mark this bug a DUP of  Bug 57292 

Comment 10

[Kathleen :Brade]

rats! bugzilla lost my comments :-(

I think Peter is right; I don't think this is a duplicate of bug #46459.  For
me, the behavior Peter is describing would be fixed for bug #57292.

btw, a workaround (if I remember correctly) is to select all but the first
character (or the last character) in the cell and you won't get the <td>.

*** This bug has been marked as a duplicate of 57292 ***

Comment 11

[sujay]

verified in 11/6 build.

Comment 12

[robinf]

I don't think this bug is a dupe of bug 57292. That bug is marked fixed, but the
behavior Peter describes still exists. Using a recent commercial build from
20020717 I still see the orginal behavior Peter describes in this bug. 

Charley - I remember you mentioning that this issue still exists - can you
comment? If you agree this is not a dupe, I will re-open and nominate for buffy.