68863 - row size shrinks when I select all rows with mouse and type text

Status: NEW

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

Description

[shrirang khanzode]

Launch composer
Create a 4x4 table
Now point the mouse in the first cell and just move it across the table thru 
al lcells so that all cells are selected(blue line appears at the starting of 
each cell)
Now, While the caret blinks in the last cell at the bottom, type some text 
Observe that the text gets written in the first cell and the two middle rows 
just shrink in height and you cannot type anymore in any cell (except the first)

I know this is not something a user would regularly do, but it's bad. The table 
rows should not change their height.

Comment 1

[Kathleen :Brade]

reassign to cmanske

Comment 2

[Charles Manske]

This is probably a "post edit DOM tree relayout" bug but I have some questions.
Minimal way to reproduce:
Create a table with 2 columns and 3 rows.
Click down in 1st cell (upper left corner) and drag to last cell lower right
corner.) Note that you *won't* see anything selected, but there actually is a
normal text range selected from the first cell to the last. (Use Composer's
"Debug | Test Selection" command to view the selection.)
When you type a character, you see the 2nd row collapse in height.

Typing a character should be equivalent to "delete selection and insert
character". But if you press delete first, and then type a character, the
character appears in the last cell and you don't see the collapsed row.
When we delete across cell boundaries, we don't delete table cell
elements, just their contents, which in this case are empty (actually "-moz-br",
Joe?).
Joe: I think this should go to layout, but can you confirm that the deletion
before character insert is doing the right thing? Why does new character appear
in 1st cell and not the last (i.e., isn't that the end of the selection?)
Why is behavior different when you press delete key first?

Comment 3

[Joe Francis]

i could tell you, but then I'd have to kill you.

Comment 4

[Joe Francis]

i bet the br's in the table cells are getting deleted.  There is probably a 
layout bug that causes those rows to then change height.

I may file a bug against layout and leave this unfixed until they fix the other 
prob (else they won't have a testcase).

Comment 5

[rubydoo123]

yes Joe, your presumption is correct, the br's are getting stripped:

BEFORE:
<table cellpadding="2" cellspacing="2" border="1" width="100%">
<tbody>
<tr>
<td valign="Top"><br></td>
<td valign="Top"><br></td>
<td valign="Top"><br></td>
<td valign="Top"><br></td>
</tr>
<tr>
<td valign="Top"><br></td>
<td valign="Top"><br></td>
<td valign="Top"><br></td>
<td valign="Top"><br></td>
</tr>
<tr>
<td valign="Top"><br></td>
<td valign="Top"><br></td>
<td valign="Top"><br></td>
<td valign="Top"><br></td>
</tr>
<tr>
<td valign="Top"><br></td>
<td valign="Top"><br></td>
<td valign="Top"><br></td>
<td valign="Top"><br></td>
</tr>
</tbody>
</table>



AFTER:
<table cellpadding="2" cellspacing="2" border="1" width="100%">
<tbody>
<tr>
<td valign="Top">hi</td>
<td valign="Top"></td>
<td valign="Top"></td>
<td valign="Top"></td>
</tr>
<tr>
<td valign="Top"></td>
<td valign="Top"></td>
<td valign="Top"></td>
<td valign="Top"></td>
</tr>
<tr>
<td valign="Top"></td>
<td valign="Top"></td>
<td valign="Top"></td>
<td valign="Top"></td>
</tr>
<tr>
<td valign="Top"></td>
<td valign="Top"></td>
<td valign="Top"></td>
<td valign="Top"><br></td>
</tr>
</tbody>
</table>

Comment 6

[Joe Francis]

fixed

Comment 7

[sujay]

Shrir, can you verify this one and mark verified-fixed?

thanks.

Comment 8

[shrirang khanzode]

i can't, right now...my NT build is blocked with bug 108530.

Comment 9

[sujay]

Shrir, is this working for you now?

Comment 10

[shrirang khanzode]

this seems more funkier than ever(hard to describe).Drop by my cube and I will 
show it to you. Am using 0211 trunk on winNT. 

Comment 11

[sujay]

REOPEN,

Shrirang demonstrated a related problem to this bug.

1) launch netscape
2) launch composer
3) enter 4 x 4 table
4) select all cells
5) type text

at this point notice the rows below have shrunk and things are
kind of screwed up in the cells.

Comment 12

[Kevin McCluskey (gone)]

Moving to Mozilla1.1. Engineers are overloaded with higher priority bugs.

Comment 13

[Joe Francis]

The days of having a half dozen milestones out in front of us to divide bugs 
between seem to be gone, though I dont know why.  Lumping everything together as 
far out as I can.  I'll pull back things that I am working on as I go.

Comment 14

[Joe Francis]

[ushing these out as far as bugzilla will let me.  I'll pull them back as I work
on them.

Comment 15

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=5 years untouched DOM/Storage bugs' priority.

If you have reason to believe this is wrong (especially for the severity), please write a comment and ni :jstutte.