fixed table layout problem with bottom cell border

VERIFIED WORKSFORME

Status

()

Core
Layout: Tables
P3
normal
VERIFIED WORKSFORME
18 years ago
17 years ago

People

(Reporter: James Lariviere, Assigned: karnaze (gone))

Tracking

({pp, regression, testcase})

Trunk
mozilla0.9.1
x86
Windows 98
pp, regression, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(5 attachments)

(Reporter)

Description

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

Comment 1

18 years ago
Created attachment 10660 [details]
test case -- bad rendering
(Reporter)

Comment 2

18 years ago
Created attachment 10661 [details]
good rendering with out fixed table layout declared in css
(Reporter)

Comment 3

18 years ago
Created attachment 10662 [details]
good rendering -- with out html width declared for table but has fixed table layout declared in css.

Comment 4

18 years ago
ryhan_ut@yahoo.com  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.

(Reporter)

Comment 5

18 years ago
Well now that was cool.  The rendering bug was fixed since yesterday.  One less 
to squash!
Status: UNCONFIRMED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 6

18 years ago
Verified with 2000-07-07-10.
Status: RESOLVED → VERIFIED
(Reporter)

Comment 7

18 years ago
This bug seems to be back.
Status: VERIFIED → UNCONFIRMED
Resolution: FIXED → ---

Comment 8

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

Comment 9

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

Comment 10

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

18 years ago
assuming this is reproducible, yes it is a regression.  I still can't reprod it.
(Reporter)

Comment 12

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

18 years ago
With 2000080714 WinNT the first cell of the first testcase is not aligned to
bottom, is that what you see James?
(Reporter)

Comment 14

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

Comment 15

18 years ago
Created attachment 12675 [details]
screenshot of test case with bad rendering

Comment 16

18 years ago
Confirming the bug with WinNT 200080714. I can perfectly reproduce the problem
James has seen.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

18 years ago
QA Contact: desale → chrisd

Comment 17

18 years ago
I can confirm this on Win98 with the 2000090504 build.

--chris

Comment 18

18 years ago
Testing on Win98 with 9/12 build, cannot reproduce the problem.
(Reporter)

Comment 19

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

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

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

Comment 22

18 years ago
Still the same bananas on build 1000102208
(Reporter)

Comment 23

18 years ago
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).
Keywords: regression
Summary: css declared fixed table layout problems with cell borders → fixed table layout problem with bottom cell border

Comment 24

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

Updated

18 years ago
Keywords: testcase

Comment 25

18 years ago
Created attachment 20514 [details]
Another test case which demonstrates this bug

Comment 26

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

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

Comment 28

18 years ago
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 :-)
(Assignee)

Comment 29

17 years ago
Moving to m0.9.1
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.1

Comment 30

17 years ago
QA contact update
QA Contact: chrisd → amar
(Assignee)

Comment 31

17 years ago
I'm not seeing the problem, marking worksforme.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago17 years ago
Resolution: --- → WORKSFORME

Comment 32

17 years ago
Yep, this bug seems to have been fixed. Tested on W2K with build 2001031604.
(Reporter)

Comment 33

17 years ago
Yahoo! :-)

Marking verified.
I think that this was probably fixed when you checked in the row height stuff a
few days ago.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.