Closed Bug 42443 Opened 24 years ago Closed 24 years ago

Empty cell isn't added when table too narrow and sizes are given in percent

Categories

(Core :: Layout: Tables, defect, P3)

defect

Tracking

()

VERIFIED FIXED
mozilla0.8.1

People

(Reporter: sicking, Assigned: bernd_mozilla)

References

()

Details

(Keywords: testcase, top100)

Attachments

(7 files)

In the attached testcase a third cell should be added on the first row since the last row contains three columns. This works correctly when the browserwindow is above 400px wide. However if you decrease the width of the window the extracell will dissapear when the window is approx 400px wide. Steps to reproduce: 1. Load the attached testcase 2. Make your browser wide. ( > 500px) 3. decrease the width of the browserwindow slowly Expected behaviour: The table should become more and more narrow as the width of browser decreases but always contain 3 columns Actual behaviour: At approx 400px the third column dissapears. Testcase is simplifyed from http://www.altavista.com where the top banner shows a simular jumping behaviour. tested on Win89SE with build 2000-06-13-11 At approx 400px the third cell at
The 3rd column is too wide at larger viewport widths. I need to change things so that bogus columns due to excessive colspans either (1) get no allocation (like IE, I think) or (2) they get a minimal amount (like Nav). Jonas, Can you explain the problem with the url which led you to develop the test case. Thanks.
Status: NEW → ASSIGNED
Target Milestone: --- → M19
1. Go to http://www.altavista.com 2. Make your mozilla window approx 1000px wide. 3. Watch the banner ad 4. Slowly decrease the width of the window When the browser is approx 800px wide the banner will make a jump. One interesting thing is that neither Mozilla or WinIE5 makes the table width in the testcase 100%. The CSS2 spec dosn't mention how this should be handeled but the HTML4 spec says that the table should contain 3 columns. Mozilla seems to differ in behavouir between <td colspan=3> and <td><td><td> when calculating the number of columns shown which is wrong. I think that the best and easiest way to handle this is to add an extra anonymous table cell at the end of the first row. The cell should have "exmpty-cells:hide". This could be done in all cases when cells don't add up to a full matrix. (should I file that as a seperat bug?)
QA Contact: desale → chrisd
Marking mozilla0.8.
Target Milestone: --- → mozilla0.8
Attached patch patch to fix the bug (deleted) — Splinter Review
I think it is better to handle over specified colspans (at the end of the table) the way IE does and drop off the columns that have no originating cells. This is what recent changes to table code have done. The attached patch fixes a problem introduced by the new code when viewing the 1st attachment.
sr=buster
I think it's wrong to differ between <td colspan=3> and <td><td><td>. IMO it's better to *always* add extra ananymous cells to fill up to an entire matrix, then to in some cases try to be "intelligent" and remove/shrink cells.
can this be checked in soon? It would be nice to have one less crasher in Mozilla 0.7 :) -Asa
The patch was checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Attached image how the testcase should render (deleted) —
Attached image how the testcase should not render (deleted) —
Attached image how the testcase should render (deleted) —
Attached image correct testcase look third attempt (deleted) —
The testcase has regressed due to checkin for bug 46623. I think it should be urgently fixed.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: mozilla0.8 → mozilla0.9
Moving to mozilla0.8.1
Target Milestone: mozilla0.9 → mozilla0.8.1
i will take this one
Assignee: karnaze → bernd.mielke
Status: REOPENED → NEW
Attached patch patch (deleted) — Splinter Review
Keywords: patch, review
finally I got the stuff throught the regression tests. The following regression tests failed: other/misc.html bugs/bug1188.html bugs/bug8858.html bugs/bug60807.html bugs/bug42443.html misc.html and bug1188.html are identical and correctly rendered, so the failure is caused by internal row redistribution. The same is true for bug8858.html. bug60807.html significantly improves while it is not absolutely perfect. I think I have thorougly tested the patch. ( I found several other regressions, down to a topcrash.)
[s]r=attinasi
fix checked in
Status: NEW → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
QA contact update
QA Contact: chrisd → amar
This was fixed.. The table gets resized with the window resize.. Verified on 2001-07-27-00-0.9.2 build.. Marking verified
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: