98537 - Interpret selection across table cell boundaries when executing table commands (e.g., Delete Rows or columns)

Status: VERIFIED FIXED

(SeaMonkey :: Composer, defect)

Description

[sujay]

This is the original description from bug 78400:
See this on
Win 2001-04-30-06Mtrunk
Linux 2001-05-01-08Mtrunk
Mac 2001-05-01-04Mtrunk

Steps to repro:
1)Open a new compose page, Create a table of 2 columns and 5 rows.
2) Click and drag down from 2nd row to 4th row to select these rows.
3)Select the menu option Table-->Delete-->Row(s)

Actual results: Only the first row gets deleted. The rest of the selected rows
remain intact.

Nominating nsbeta1 for implied functionality not present.
We should either change the wording from
Table-->Delete-->Row(s)
to
Table-->Delete-->Row
or make this functionality actually available to users.

Implementation for deleting multiple rows or columns when mulitple *cells* are
selected was done and that bug was closed.
So this issue described above is really asking us to interpret a *text*
 selection (find all cells included in the text selection) when doing table
commands.



------- Additional Comments From [e-mail] 2001-06-12 14:41 -------

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



------- Additional Comments From Peter Trudelle 2001-06-12 16:04 -------

I don't think typical users will make such a distinction between how the
selection was made.  If it spans rows/columns, then the commands will be
expected to affect them.  I've been deleting each column separately (Alt-O,
b-d-o) for some time now, thinking that the command just couldn't handle more
than one row/column at a time. It never even occurred to me that I could be
saving myself all those keystrokes by using command-click.  Of course, I could
be one of your least savvy users.



------- Additional Comments From Charles Manske 2001-06-12 18:17 -------

No, you have discovered the difficulty with sharing selection between Browser
and Composer. The typical behavior for word processors is to snap into "select
table cell" mode once you drag from one cell to another. We did that initially
and got lots of negative feedback because, unfortunately, hidden (border=0) HTML
tables are used all over the place, so users didn't realize they were in a
table.
Thus we had to compromise and require the extra "table mode" key: Cmd for Mac,
Ctrl for the rest. Once you realize this, table selection is actually quite
easy.
So this bug will be tricky to fix, and will NOT end up with a selection of
table cells, but at least we intend to make the table methods work with text
selection spanning cells. (Note that you can never select columns that way,
must use the Ctrl key for this.)

Comment 1

[sujay]

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

Comment 2

[Charles Manske]

I think it would be much better to support the standard 'snap to cell-only' 
selection model, but in Compose only. Bug 98558 covers this issue.
If that is fixed, this bug becomes a "wontfix", since it will not be necessary 
to interpret text-only selection across cell boundaries (that won't be possible.)

Comment 3

[Syd Logan]

spam composer change

Comment 4

[Kathleen :Brade]

This is the bug I ran into yesterday.
I don't think we can count on bug #98558 being fixed any time soon.  :-(

Comment 5

[Charles Manske]

Changing milestone

Comment 6

[Syd Logan]

Here's what I would do. If no rows or cells have been ctrl-click selected, make
the delete menu items disabled. If we simply make the user select cells and rows
before they can be deleted, this usability problem goes away. I personally find
it difficult to believe that allowing the user to delete a row or cell just
because that row or cell has focus is a good thing. Why? You have to select text
to Cut, or Copy in an editor. You have to select objects in a drawing program to
Cut, Copy, or Move them. Why should it be any different for cells or rows in a
table? I think there might be a discovery issue, but once you know how it works,
it is very natural. I'd say we are just about there with some very nice
functionality, let's just make selection a requirement for these menu items to
be active, and I think we are there.

Comment 7

[Brian S. Craigie]

I disagree.

If I drag select over three rows and then do Format -> Table -> Delete ->
Rows(s)  (note the (s) implies it will delete more than one row) it should do
what I ask, and not just delete one row.  Doing this control-drag nonsense is
not necessary and not intuitive.  What reason is there to assume the user is an
idiot and just delete one row?  That's Microsoft philosophy. ;-)

Comment 8

[Charles Manske]

Mjudge will be fixing table selection in bug 98558. Then dragging out of a cell
will automatically select cells and this problem will go away.

Comment 9

[Charles Manske]

More milestone load balancing

Comment 10

[Charles Manske]

Fix for bug 98558 is checked in, so this is no longer an issue

Comment 11

[sujay]

verified in 3/24 Mac build.