Closed
Bug 91179
Opened 24 years ago
Closed 23 years ago
applying font size/style changes on a large table causes problem
Categories
(Core :: DOM: Editor, defect)
Core
DOM: Editor
Tracking
()
VERIFIED
WORKSFORME
People
(Reporter: sujay, Assigned: attinasi)
References
()
Details
(Whiteboard: EDITORBASE)
Attachments
(2 files)
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 2•23 years ago
|
||
*** This bug has been marked as a duplicate of 67260 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
REOPEN...still a problem...closed out master bug 98535
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
I should have mentioned that I still see this on branch using 10/4 build.
Comment 6•23 years ago
|
||
Comment 7•23 years ago
|
||
Comment 8•23 years ago
|
||
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.
Updated•23 years ago
|
Whiteboard: EDITORBASE
Comment 9•23 years ago
|
||
Am I correct in understanding that this is fixed on the trunk, but still a
problem on the branch?
Comment 10•23 years ago
|
||
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.
Reporter | ||
Comment 11•23 years ago
|
||
this is not fixed in the 10/5 branch build.
I will try this out on trunk also...
Reporter | ||
Comment 12•23 years ago
|
||
okay this is not a problem on the 10/5 trunk.
Comment 13•23 years ago
|
||
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•23 years ago
|
||
Marking WORKSFORME, since it is working correctly on the trunk.
Status: NEW → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•