91179 - applying font size/style changes on a large table causes problem

Status: VERIFIED WORKSFORME

(Core :: DOM: Editor, defect)

Description

[sujay]

I tried to come up with a reduce test case, but the problem happens when you
have a large table like the URL above. works fine with small tables.
I think this is another table layout problem.

1) launch netscape
2) jump to above URL
3) bring that page into editor
4) hit Select-All
5) click on "-a" on toolbar to decrease font size

look at the page and notice the following problems:

 a) table is totally screwed up, misaligned rows and columns all over the place
 b) table cells outside table borders
 c) table grid is messed up( cells are farther apart from each other)

6) Ctrl-Z

after doing this, the table grid is not back to normal.

Comment 1

[rubydoo123]

this would go to karnaze

Comment 2

[Kathleen :Brade]

*** This bug has been marked as a duplicate of 67260 ***

Comment 3

[sujay]

verified.

Comment 4

[sujay]

REOPEN...still a problem...closed out master bug 98535

Comment 5

[sujay]

I should have mentioned that I still see this on branch using 10/4 build.

Comment 6

[karnaze (gone)]

Attachment: simple test case where applying +a to contents fails on current m0.9.4 and older trunk builds

Comment 7

[karnaze (gone)]

Attachment: assertion to catch block changing its width during resize reflow

Comment 8

[karnaze (gone)]

I'm seeing the problem in the 1st attachment by selecting everything with ctl-a 
and then hitting the +a button in mozilla. The problem exists on the 9/27/1 
trunk, not on the 10/3/1 trunk (I seem to recall, but can't verify right now), 
and on the 10/3/1 m094 branch, so maybe some block change which fixes this made 
it into the trunk but not the branch.

There are a couple of problems. The +a is causing a lot of extraneous content to 
get generated and new frames to be constructed. A new row group gets constructed 
and existing rows get a lot of new empty cells. But this problem appears to have 
existed for a long time and is overshadowed by the next problem:

The 1st cell's block reports a max width of 2250 during the initial reflow
 
    Cell 02885790 r=0 a=UC,UC c=UC,UC cnt=4
     Block 028857EC r=0 a=UC,UC c=UC,UC cnt=5
     Block 028857EC d=2190,285 me=600
    Cell 02885790 d=2250,345 me=660

but later (it is now probably the 2nd cell in the row due to the new frames 
mentioned above) it requests a max width of 60

    Cell 02885790 r=1 a=4905,UC c=4845,UC cnt=57
     Block 028857EC r=1 a=4845,UC c=4845,UC cnt=58
     Block 028857EC d=4845,300 me=0 m=0
    Cell 02885790 d=4905,360 me=60 m=60

so, that when it does try to correct the situtation during the resize reflow, 
its too late for the table to react. The assertion is attachment #2 [details] [diff] [review].

    Cell 02885790 r=2 a=60,UC c=0,UC cnt=76
     Block 028857EC r=2 a=0,UC c=0,UC cnt=77
     Block 028857EC d=735,1500
    Cell 02885790 d=795,1560
###!!! ASSERTION: block changed its width during resize reflow: 'desiredSize.wid
th <= kidAvailSize.width', file S:\mozilla\layout\html\table\src\nsTableRowFrame
.cpp, line 887

Adding nsbranch keyword, and reassigning to attinasi, although waterson may know 
what could fix this on the branch.

Comment 9

[Chris Waterson]

Am I correct in understanding that this is fixed on the trunk, but still a
problem on the branch?

Comment 10

[karnaze (gone)]

yes, but I can't reconfirm that right now because my home system has older 
builds on it. The branch build on which it failed on my office machine was 
10/3/1 (I think), so I guess with some luck it could even be fixed on todays 
branch build.

Comment 11

[sujay]

this is not fixed in the 10/5 branch build.

I will try this out on trunk also...

Comment 12

[sujay]

okay this is not a problem on the 10/5 trunk.

Comment 13

[Kevin McCluskey (gone)]

Marking nsbranch-. 6.1 fails in the same manner as described in this bug and we
don't have a patch ready to go to fix this.

Comment 14

[Kevin McCluskey (gone)]

Marking WORKSFORME, since it is working correctly on the trunk.

Comment 15

[sujay]

verified.