57292 - selection of content in table is too picky; picks up td

Status: VERIFIED FIXED

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

Description

[Frank Tang]

reproduce procedure
1. open http://pb
2. find beppe
3. select her AIM ID: "rubydoo123"
4. copy
5. open composer
6. paste
expect result
rubydoo123 paste into the new document
actual result
rubydoo123 in  a table cell paste into the document.

Comment 1

[rubydoo123]

that is probably doing exactly what you asked it to do, what gets copied and
pasted is determined by how and what you select. For example, if you dbl-click
rubydoo123 you will get plaintext, if you triple-clk you will get the text and
the table data.

Comment 2

[sujay]

verified in 10/20 build.

Comment 3

[Frank Tang]

I neither double nor triple select. I just use mouse select from the beginning 
of the text to the end of the text. let me change the step 3 to a better 
description here
3. point mouse to the beginning of "rubydoo123", click the mouse button, drag to 
the end of the "rubydoo123" to select it. 

Comment 4

[rubydoo123]

Frank, you are probably selecting past the word, hence grabbing the structure.
If you go to the beginning of a word and select shift-end, you will get the text
only, if you drag select and happen to drag past the word boundry (witch is very
easy to do) you will get the structure. The dragging past the selection (similar
to triple-click) will result in the structure selection.

Remarking as invalid

Comment 5

[sujay]

verified in 10/24 build.

Comment 6

[Frank Tang]

beppe- I think this is not an invalid bug. As you said, it is very easy to 
select past the word. I hope you can understand that no user can tolarate this 
kind of behavior. I understand we have limited time, but this is definitely one 
userability issue you folks should try to address.  Here are several suggsetion 
I can make to improve the UI
1. if the editor belive the user select the whole cell (the structure), then the 
composer should show the user the whole cell is selected by drawing a bolder 
outline when that happen.
2. There should be enough space for the user to just select the whole content 
without select the cell (the sturcutre) itself.

I totally understand it is impossible to address this in our Netscape6 RTM. But 
I think this is an valid bug that we need to address in the UE stage.

Comment 7

[Katsuhiko Momoi]

I second Frank in this. I have not been able
to select just one word I want if I use the mouse
to sweep over it in a table cell.
The only way to achieve that is by double-clicking on it,
or triple-clicking on it if it contains more than 1 word.

It practically impossible to select just the words
without the table cell structure just by sweeping over it.

Do you have a spec for the sweeping selection method?

Comment 8

[Kathleen :Brade]

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

Comment 9

[Kathleen :Brade]

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

Comment 10

[Kathleen :Brade]

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

Comment 11

[Kristi Fredrickson]

Adding to RTM Release Notes

Comment 12

[Peter Trudelle]

Having to select only partial contents to avoid getting the container is not
discoverable, and in any case unacceptable.  It seems that the current
implementation is not even consistent, since copy will include the container of
the selection, but cut or delete does not. Thus, on paste you can get an
invisible container with no obvious way to remove it.  If something is included
in the selection, it should be obvious at the time you select it, not implicit
in the amount of the contents selected.  If the only thing being selected is
text, then only text should be cut/copied/deleted.  We should optimize for the
typical case (text only), and the exceptional case (cells) can and should be
more difficult, or at least not the default behavior.

Comment 13

[rubydoo123]

Deleting a cell (or cutting) has a special line item within the Table menu and
is treated differently than a copy/paste operation -- which is correct.
Manipulating a tables content and structure is a completely different operation
than copy paste from a table to another location. Within the table menu, under
delete, the user can choose to either delete the content of the cell or delete
the cell and the cell content.

In regards to the copy paste operation that is being addressed here, currently,
we do not have a special paste operation for text only or text and cell (or
container). That is being addressed in the next release. I beleive this bug and
bug 58807 should be attached or duped or whatever to bug 41547 (Paste Special
submenu is missing), so this type of scenario will not get passed over when the
Paste Special option is included.

A visible indicator on what gets selected for the copy paste operation is
something we could address as well, possibly outlining the cell with a dashed
line, or in the case of other container elements like li, we could apply a
border around the container, or maybe gray out the frame. That may make it at
least more apparent to the user that they have selected more than just the text.

Typical case is also quite relative to the user and the objects being selected.
It is also relative to the current need of the user at the time of the action --
the user may one time wish to just grab the content and at other times wish to
grab the content and the table. I would suspect that the user would want to have
the capability of doing both, which is what we plan on providing to the user in
the next release.

Comment 14

[Peter Trudelle]

I disagree that copying text is a special operation, it is fundamental, and used
frequently by almost everyone.  It is a typical usage case; copying cells is the
special case that is used very infrequently by a tiny number of users, and can
be reduced to two fundamental operations, insert cell and paste contents.
As to providing for table delete, how does a user who has just pasted an
invisible table along with the text they copied even know that they have it, in
order to be able to choose the right commands to get rid of it?  The current
default behavior is just wrong, IMO, and whatever bug you want to leave open
will have to address that.

Comment 15

[Charles Manske]

I will be examining this problem ASAP, but a quick comment: Selecting by simple
dragging of mouse in table cells should *never* pick up container cells -- only
the cell contents should be copied to clipboard. That was original design; 
sounds like it didn't turn out that way!

Comment 16

[Charles Manske]

The bug is in determining what to copy: When doing "text selection", just dragging
mouse over cell contents, we should never pick up table or cell nodes unless the
the table is completely "enclosed" by the selection. Any selection that is within
a table (and not around a nested table) should ignore the cells it encounters.
I think Joe owns this issue now.

Comment 17

[Joe Francis]

i think i have a bug on this already.  at any rate, it will be fixed by my next 
large landing (which will include whitespace work, though that's unrelated).

Comment 18

[Charles Manske]

Joe is on top of this issue.

Comment 19

[rubydoo123]

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

Comment 20

[Kristi Fredrickson]

Replacing kristif with robinf. Robin Foster-Clark is now the docs owner for 
Composer.

Comment 21

[Joe Francis]

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

Comment 22

[Kathleen :Brade]

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

Comment 23

[Kathleen :Brade]

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

Comment 24

[Kathleen :Brade]

Here are Joe's comments from bug #57736:

------- Additional Comments From [e-mail] 2000-10-25 15:24 -------

I should alter the copy code to stop range promotion when a td is encountered.  
Users have cell selection mode if they really want to select the whole td.

Comment 25

[Joe Francis]

Attachment: patch for layout/base/src/nsDocumentEncoder.cpp

Comment 26

[Joe Francis]

fix attached in above patch.  need review/sr.  akkana, simon?

Comment 27

[Simon Fraser [no longer active]]

sr=sfraser

Comment 28

[Akkana Peck]

r=akkana

Comment 29

[Joe Francis]

fixed

Comment 30

[sujay]

verified in 4/5 build.