In Del and Clear (on Mac) key handlers, call nsITableEditor::GetFirstSelectedCell() to test if we are in cell selection mode. If it returns an element, call nsITableEditor::ClearCellContents() so table table structure is not disturbed. That method *will* delete entire cells only if all the cells in a column or row are selected.

Oops, the method you should call is nsITableEditor::DeleteTableCellContents().

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

setting to m17

accepting bug

nominating for b3

Added correctness and nsbeta3+

setting priority in status whiteboard

m18

Per PDT, marking beta3-minus. Discussion at the PDT also questioned this as a feature, and not just whether it should be a minus. The general belief was that when you pressed "del" you should remove not only the content, but also the containing tables/forms. Consider the fact that when you select a paragraph, and press delete, the contents of the paragraph are vanquished, and so are the lines of spacing. ...well... that's we we saw it... Jim (on behalf of the PDT triage)

The editor team has discussed this issue thoroughly and I don't appreciate the PDT team second-guessing our decisions. Deleting table *cells* is the issue and if delete key does that, it will quickly lead to a completely mangled table, because the number of cells in each row are not balanced. This is probably not what the average user wanted. It an entire table is selected, of course it will be deleted. This is not a new feature -- this behavior is completely implemented and used via the Table | Delete menu. This bug was simply to have Joe test if you are in a table when delete key is pressed and call the table-editor method. We already discussed doing that. Removing status whiteboard values.

fixed

Works for Me Platform: PC OS: Windows 98 Mozilla Version: 2000100508 Marking as Verified