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

VERIFIED FIXED in mozilla0.8.1

Status

()

P3
normal
VERIFIED FIXED
19 years ago
18 years ago

People

(Reporter: sicking, Assigned: bernd_mozilla)

Tracking

({testcase, top100})

Trunk
mozilla0.8.1
testcase, top100
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(7 attachments)

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
Keywords: testcase, top100

Comment 2

19 years ago
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?)

Updated

19 years ago
QA Contact: desale → chrisd

Comment 4

18 years ago
Marking mozilla0.8.
Target Milestone: --- → mozilla0.8

Comment 5

18 years ago
Created attachment 21055 [details] [diff] [review]
patch to fix the bug

Comment 6

18 years ago
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.

Comment 7

18 years ago
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.

Comment 9

18 years ago
can this be checked in soon?  It would be nice to have one less crasher in
Mozilla 0.7 :)
-Asa

Comment 10

18 years ago
The patch was checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
(Assignee)

Comment 11

18 years ago
Created attachment 26547 [details]
how the testcase should render
(Assignee)

Comment 12

18 years ago
Created attachment 26548 [details]
how the testcase should not render
(Assignee)

Comment 13

18 years ago
Created attachment 26549 [details]
how the testcase should render
(Assignee)

Comment 14

18 years ago
Created attachment 26550 [details]
correct testcase look third attempt
(Assignee)

Comment 15

18 years ago
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

Comment 16

18 years ago
Moving to mozilla0.8.1
Target Milestone: mozilla0.9 → mozilla0.8.1
(Assignee)

Comment 17

18 years ago
i will take this one
Assignee: karnaze → bernd.mielke
Status: REOPENED → NEW
(Assignee)

Comment 18

18 years ago
Created attachment 27169 [details] [diff] [review]
patch
(Assignee)

Updated

18 years ago
Keywords: patch, review
(Assignee)

Comment 19

18 years ago
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.)

Comment 20

18 years ago
[s]r=attinasi
(Assignee)

Comment 21

18 years ago
fix checked in
Status: NEW → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED

Comment 22

18 years ago
QA contact update
QA Contact: chrisd → amar

Comment 23

18 years ago
 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.