Closed Bug 57292 Opened 24 years ago Closed 24 years ago

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

Categories

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

Product:
Core
Component:
DOM: Editor
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9

People

(Reporter: ftang, Assigned: mozeditor)

References

Details

Attachments

(1 file)

patch for layout/base/src/nsDocumentEncoder.cpp
452 bytes, patch
Details | Diff | Splinter Review 
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.
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.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
Summary: Copy and past content in table behave starnge → Copy and past content in table behave strange
verified in 10/20 build.
Status: RESOLVED → VERIFIED
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.
Status: VERIFIED → REOPENED
Resolution: INVALID → ---
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
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → INVALID
verified in 10/24 build.
Status: RESOLVED → VERIFIED
Status: VERIFIED → REOPENED
Resolution: INVALID → ---
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.
Summary: Copy and past content in table behave strange → selection of content in table is too picky; picks up td
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?

*** Bug 58807 has been marked as a duplicate of this bug. ***
*** Bug 58807 has been marked as a duplicate of this bug. ***
*** Bug 58807 has been marked as a duplicate of this bug. ***
Adding to RTM Release Notes
Keywords: relnoteRTM
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.
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.
Assignee: beppe → cmanske
Status: REOPENED → NEW
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.

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!
Severity: normal → major
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9
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.
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).

Joe is on top of this issue.
Assignee: cmanske → jfrancis
Status: ASSIGNED → NEW
*** Bug 61896 has been marked as a duplicate of this bug. ***
Replacing kristif with robinf. Robin Foster-Clark is now the docs owner for 
Composer.

*** Bug 62959 has been marked as a duplicate of this bug. ***
*** Bug 68600 has been marked as a duplicate of this bug. ***
*** Bug 57736 has been marked as a duplicate of this bug. ***
Here are Joe's comments from bug #57736:

------- Additional Comments From jfrancis@netscape.com 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.

fix attached in above patch.  need review/sr.  akkana, simon?
Status: NEW → ASSIGNED
Whiteboard: fix in hand; need review
sr=sfraser

r=akkana
fixed
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Whiteboard: fix in hand; need review
verified in 4/5 build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: