112857 - Deleting cell(s) inside of tables will not remove cell(s)

Status: RESOLVED EXPIRED

(SeaMonkey :: Composer, enhancement)

Description

[TucsonTester1]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.6+)
Gecko/20011126 Netscape6/6.1b1
BuildID:    2001112608

Deleting cells inside of a table, whether using dropdown menu or  cntrl-click
will not delete the cell.

Reproducible: Always
Steps to Reproduce:
1.Open Navigator
2.Open Composer
3.Create table (using either defaults or customized table size - I used a 5*5
table, and a 3*2 table for multiple tests)
4.Select a cell near the middle of the table
5.Click on Table Menu (Mac OS X)
6.Go to Delete submenu
7.Click on Cell(s)  [Notice cell is not deleted]
8.Hold down control key
9.Click on cell (either same one or any other one)
10.In the menu that comes up, click on Table Delete
11.In the submenu, click on Cell(s)


Actual Results:  In both scenarios, cells are not deleted from the table.

Expected Results:  I expect that if I click on delete cell(s), that the cell(s)
be deleted.

Comment 1

[TucsonTester1]

Noticed same behavior on Windows 95, 98, 2000, and XP
The cell will delete but it adds another cell in the last row (composer in 4.78
does not act the same way)
Steps to reproduce:
1. Insert a table into the new document. (use three rows, three columns)
2. In the beginning of each cell in the first row, type a number. (1 in the
first cell, 2 in the second cell..)
3. Position the cursor in the second cell.
4. On the Mac, mouse down and select Delete Cell. On Windows, right click and
select Cell from the Delete submenu.

Actual Results: The second cell is deleted from the table. The third cell is
moved over to the second cell's position, but a new cell is automatically added
to the third column.

Expected Results: The second cell is deleted from the table. The third cell is
moved over to the second cell's position, but a new cell should not be added to
the third column (same test on composer in 4.78 did not add a new cell).

Note: If you select to insert a new cell composer adds a new column at the end
of the table.  Composer in 4.78 does not add a new column.

Comment 2

[Greg K.]

Confirmed using Fizzilla/2001112020 (0.9.6). If Table Cell Delete is not going to have any 
effect on a single table cell, it should be inaccessible (greyed) in the menus.

Comment 3

[TucsonTester1]

I have found that this is working as designed - it is a user preference that is
causing the table to add a column
1. select Edit
2. click Preferences
3. under Table Editing uncheck Maintain table layout when inserting or deleting
cells

after that inserting and deleting cells works in the same way as the composer in
4.78

Comment 4

[TucsonTester1]

Checking back on this bug using the 2001113008 build...

If the preference is unchecked, when you delete a cell on Mac OS X, then it will
remove the highlighted cell, and move the remaining cells over, leaving the
empty cell in the far right column. My thoughts on this would be that if the
cell is removed, a blank cell should be left in the place where the cell was
deleted, because sometimes while creating tables, I know that's how I would like
it to be done. 

Comment 5

[TucsonTester1]

The previous comment was made on build 2001113008. This was again tested on
build 2001120308, and is still happening as defined previously.

Comment 6

[Syd Logan]

Marking enhancement based on comments made 12/03

Comment 7

[Kathleen :Brade]

reassign to new account

Comment 8

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 9

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420