Closed
Bug 321154
Opened 19 years ago
Closed 17 years ago
Dynamically setting a table's table-layout to fixed causes rendering problems.
Categories
(Core :: Layout: Tables, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: ian, Unassigned)
References
Details
(Keywords: testcase)
Attachments
(2 files)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Dynamically changing the table-layout style attribute to fixed and filling the table's body (by executing some Javascript) after a table has been loaded results in various table rendering problems.
Reproducible: Always
Steps to Reproduce:
1.Load attached test case
2.Notice that the bottom table renders outside it's enclosing div.
3.Click the "Refill tables" button, now both tables will render correctly.
4.Uncheck the box labeled 1 to hide column 1, Tables render correctly.
5. Uncheck the box labeled 3, Tables render correctly.
6. Check box labeled 3, notice that the bottom table renders incorrectly, seems like the header is displayed over another header, and the column's contents are not displayed.
7. Uncheck boxes 4 and 5, notice that column 3's header seems to render outside the table, and it's contents are not displayed.
Actual Results:
The tables don't render in the same way, they did under 1.0.7 (note I haven't tried this specific reduction in 1.0.7 but the code that the reduction came from works correctly in 1.0.7).
Expected Results:
It should have rendered both tables the same way during each step.
I also tested against the latest nightly build (1.6a1) downloaded from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ and got the same incorrect behavior.
The behavior I'm depending on is having a cell (td) truncate it's content by setting it's overflow:hidden, and also having that cell take up all the remaining space in a table (when some of the columns are hidden).
Reporter | ||
Comment 1•19 years ago
|
||
Updated•19 years ago
|
Component: General → Layout: Tables
Product: Firefox → Core
QA Contact: general → layout.tables
Version: unspecified → Trunk
Comment 2•19 years ago
|
||
As a related bug, I'm having issues collapsing columns on the initial page load when table-layout is set to fixed. If I reset the table-layout dynamically from fixed to auto and back, my problem is solved.
I've also done some experimenting in my test case with refilling the table, and I've noticed that dynamically setting the table-layout does NOT rerender the table. I'm not sure if that's intended, but it may be related.
To reproduce the problem I've found:
1. Load the second attached testcase.
2. Click the Toggle Hiding of 3rd Column button.
3. Observe that the column does NOT collapse.
4. Click the Toggle Hiding of 3rd Column button so the third column's visibility is no longer collapse.
5. Click the Toggle Layout Model of Table button; the table-layout is now auto.
6. Click the Toggle Hiding of 3rd Column button.
7. Observe that the column does NOT collapse.
8. Click the Toggle Hiding of 3rd Column button so the third column's visibility is no longer collapse.
9. Click the Toggle Layout Model of Table button; the table-layout is now fixed, again.
10. Click the Toggle Hiding of 3rd Column button.
11. Observe that the column DOES collapse.
Actual results:
The third column does not collapse on initial page load.
Expected results;
The third column should always collapse.
Comment 3•19 years ago
|
||
Comment 4•18 years ago
|
||
Maybe it has somethink to do with this:
<table
style="table-layout: fixed;"
onclick="alert('I think that this table layout is: ' + document.defaultView.getComputedStyle(this, null).tableLayout)"
>
<tr>
<td>Click here to see what the browser thinks i set</td>
</tr>
</table>
This looks to have been fixed in Firefox 3. Both of the test cases work fine.
wfm
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Flags: in-testsuite?
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•