43854 - fixed table layout problem with bottom cell border

Status: VERIFIED WORKSFORME

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

Description

[James Lariviere]

DESCRIPTION:

The combination of a Fixed table layout and a declared width (ex. <table 
width="900">) causes table cells of unequal height to render borders 
inconsistently.


STEPS TO REPRODUCE:

view test case 1 -- for "bad" rendering with fixed layout;
view test case 2 -- for "good" rendering without fixed layout;*
view test case 3 -- for "good" rendering without width declared in table;**

*The only thing I will change is the css layout property for table (for test 
case 2).
**The only thing I will change is the width declared in the table (for test 
case 3).

ACTUAL RESULTS:

test case 1:
The first cell renders with an incomplete bottom border, the other 2 cells 
render borders as expected.

test case 2:
All cell borders render as expected.

test case 3:
All cell borders render as expected.


EXPECTED RESULTS:

All cells should render with the same consistent borders no matter the height 
of text inside the cell rows.


DOES NOT WORK CORRECTLY ON:

6-25-00-m17 nightly and past builds for awhile now.

Comment 1

[James Lariviere]

Attachment: test case -- bad rendering

Comment 2

[James Lariviere]

Attachment: good rendering with out fixed table layout declared in css

Comment 3

[James Lariviere]

Attachment: good rendering -- with out html width declared for table but has fixed table layout declared in css.

Comment 4

[Bernd Mielke]

[e-mail]  are you still seeing this problem, with win98 and 2000062720 
I cannot reproduce the problem. Please attach a screenshot in case you can 
reproduce it.

Comment 5

[James Lariviere]

Well now that was cool.  The rendering bug was fixed since yesterday.  One less 
to squash!

Comment 6

[Prashant Desale]

Verified with 2000-07-07-10.

Comment 7

[James Lariviere]

This bug seems to be back.

Comment 8

[Rann Bar-On]

works for me (win95, 080108).  James: test this with the latest builds.  It
looks fine here.

Comment 9

[James Lariviere]

Sorry, I should have reported my build.  With the win98 2000080208 build, 8/2/00
build "morning", the first test case is rendering like I first reported this bug.

I'm downloading the new 8/3 build (love 56k dialups) to see if it was just one
of those daily quirks.

Comment 10

[James Lariviere]

yep this bug is still there with todays build (win98 080308).

I can say about a month ago this bug was fixed.  Is this what you label a
regression?

Comment 11

[Rann Bar-On]

assuming this is reproducible, yes it is a regression.  I still can't reprod it.

Comment 12

[James Lariviere]

dumb question but are you viewing with one of the latest builds because the one
you refered to is older than the last 2 i've used for the past 2 days?

if so, i tried this on another computer and I could still see this bug.

again in the first test case the left most cell border does not look like the
others.  the 2nd and 3rd test case shows good rendering of all table cell borders.

Comment 13

[Bernd Mielke]

With 2000080714 WinNT the first cell of the first testcase is not aligned to
bottom, is that what you see James?

Comment 14

[James Lariviere]

I took a screenshot of what I'm seeing so no one can accuse me of smokin'
something...

What is wierd about this bad rendering is that the cell renders incorrectly
everytime on first rendering the page with the browser maximized.  However, the
cell renders fine on refreshing the page and/or resizing the browser window to
something other than maximized for me on machines with different graphics cards
(voodoo3 and geforce2).

I'm attaching a screenshot.

Comment 15

[James Lariviere]

Attachment: screenshot of test case with bad rendering

Comment 16

[Bernd Mielke]

Confirming the bug with WinNT 200080714. I can perfectly reproduce the problem
James has seen.

Comment 17

[Chris Nelson]

I can confirm this on Win98 with the 2000090504 build.

--chris

Comment 18

[Christine Hoffman]

Testing on Win98 with 9/12 build, cannot reproduce the problem.

Comment 19

[James Lariviere]

I just tried the win98 build 2000091505 (sept 14th i think) and still get this
rendering problem demonstrated in the first test case, shown in a screenshot
(most recent attachment).

too bad huh...

Comment 20

[Brett Donald]

I observe this exact problem on my page
http://www.tagnet.org/castlehill/cal12.html.  The page is initially rendered
incorrectly, but if I resize the browser window it corrects itself. Magic!
Should be an easy one to fix...

Comment 21

[Brett Donald]

Sorry, I should have given you the build number with my pervious comment -
2000100408 - running on Windows 2000.

Comment 22

[Brett Donald]

Still the same bananas on build 1000102208

Comment 23

[James Lariviere]

GD! This bug is annoying because I see it on my site every day.

I searched through bonsai and could know find anything that really stuck out.
Basically, something checked in between 6-25-2k and 6-28-2k fixed it.
Then, between 6-28-2k and 7-07-2k regressed it again.

There are only 2 bugs checkin during this time frame that even look like they
could have caused this rendering problem (bug 40721 or bug 43732).

Comment 24

[Christine Hoffman]

Tested on the with the following builds:

Win 98 - 12_11_06_trunk
Linux - 12_11_11_trunk
Mac - 12_11_4_ trunk

I reproduced the bug on Windows and Linux but was unable to reproduce on Mac. 
I am seeing the same problem as shown in the 9/15 screehshot. My earlier failing 
to reproduce was because I was not looking at a maximized page. Marking this as 
a parity bug because I was unable to reproduce on Mac. 

Comment 25

[Brett Donald]

Attachment: Another test case which demonstrates this bug

Comment 26

[Brett Donald]

The additional test case I've just added demonstrates the problem even when the
browser window is small. As Chris has alluded to, James' test case only seems to
demonstrate the problem if the entire table fits inside the viewable area when
the page is first displayed (as it does on an XGA display with the browser
maximised).

This new test case also demonstrates an additional bug - setting the
border-collapse style to 'collapse' does not collapse the borders as it should.
Compare the rendering with IE. But I'm more interested in getting the first bug
fixed!!!

Comment 27

[Christine Hoffman]

Replying to Brett's comment regarding border-collapse: collapse. This feature 
was turned off for the 6.0 release as there were many problems associated with 
it. When these problems are resolved, it will be turned back on (see fixed bug 
49490 for reference). 

Comment 28

[James Lariviere]

Chris, could either of those checkins (like bug 40721) have anything to do with
this rendering bug since it seems like the dates correspond to the
worked/regression timeframe?

Also, if you check bonsai, dbaron was doing some work with margins and
padding... could this have caused this...?  Thanks :-)

Comment 29

[karnaze (gone)]

Moving to m0.9.1

Comment 30

[Amarendra Hanumanula]

QA contact update

Comment 31

[karnaze (gone)]

I'm not seeing the problem, marking worksforme.

Comment 32

[Brett Donald]

Yep, this bug seems to have been fixed. Tested on W2K with build 2001031604.

Comment 33

[James Lariviere]

Yahoo! :-)

Marking verified.
I think that this was probably fixed when you checked in the row height stuff a
few days ago.