Table Layout shows empty cells that should not be

RESOLVED WORKSFORME

Status

()

Core
Layout: Tables
RESOLVED WORKSFORME
14 years ago
12 years ago

People

(Reporter: Andreas Schildbach, Unassigned)

Tracking

Trunk
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

14 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10

I've got a rather weird problem which I long thought is my fault. But after
thorough analysis I came to the conclusion that a bug in the Gecko layout engine
is very probable.

Sometimes table cells just skip one column. Please look at the chess board
(which is a table) of the attached images and you will see what I mean.

Usually, the problem goes away (and comes again) by reloading.

I have closely expected both the HTML source and the DOM of a page that exhibits
the problem, and cannot find any error that could lead to the problem.

The problem can only be demonstrated online. Please follow the steps below to
reproduce.

I could not reproduce the problem by saving the HTML source to the local file
system and opening from there.

I could also not reproduce the problem by putting a static HTML on a web server
(tested with Tomcat). It has got something to do with dynamic generation.

Although it should be transparent to Firefox: The source which exhibits the
problem is generated with Tomcat 5.0.27 on Debian Linux and Windows XP (tried
both). The last step in the generation pipeline is an XSLT transformation.

The problem is present with Firefox PR1 and 0.9.3, also with Netscape Navigator
7.1, but not with MSIE 6 or Opera.

I have several users confirming the problem, so it should not be a speciality of
my system.


Reproducible: Sometimes
Steps to Reproduce:
1. Go to http://3moves.net
2. Click on "chess games / demo game" in the navigation bar at the left side
3. With a bit of luck, you will already see the problem now. If not, continue.
After each step, the problem can pop up
4. Click on b4
5. Click on execute move
6. Click on c5
7. Click on execute move
8. Click on d4
9. Click on execute move
10. If the problem is still not there, try to go back some moves with "undo
move" and try again

Actual Results:  
Please look at the attached images to see how the problem looks like.

Expected Results:  
Please look at the attached images to see how the page should always look.
(Reporter)

Comment 1

14 years ago
Created attachment 159029 [details]
this image exhibits the problem (marked in red)

Please note that the white fields on d2 and e4 (actually d4, because the
problem moves the cell to the right) are normal as they indicate the last move
(Reporter)

Comment 2

14 years ago
Created attachment 159030 [details]
this image looks as it should be

Updated

14 years ago
Assignee: firefox → general
Component: General → Browser-General
Product: Firefox → Browser
QA Contact: firefox.general → general
Version: unspecified → Trunk

Comment 3

14 years ago
WFM, 2004-09-13-06 trunk Linux.

Comment 4

14 years ago
I get the actual results (2 empty cells on 4th rank creating an offset to the
right) at this precise url:

http://3moves.net/game/demo/start_game.html?game_tag=chess

and I get the actual results after following the steps to reproduce (1.b4 c5 2.d4)

Also similar problem of the checkerboard (table rendering) at:
http://3moves.net/game/demo/start_game.html?game_tag=checkers

Mozilla 1.8a4 build 2004091406 under XP Pro SP2 here.

I get the expected results with a reload of the page though; so this is most
likely a redraw/reflow issue with tables. A quick scanning of the page and of
the table does not reveal what maybe the problem with the table; there are 11
table cells per table row.

This bug may have been reported before. Also, such layout problem does NOT
deserve Severity: major. I'm leaving this bug unconfirmed until we can establish
for sure that there isn't a DUPLICATE for this bug.

Creating a *reduced* testcase of that page would help (without the move input
and related javascript).
Severity: major → normal
Whiteboard: DUPEME
(Reporter)

Comment 5

14 years ago
I'll try to prepare a reduced testcase that still exhibits the bug. However, the
Javascript code does nothing more than activating the text box. It is not needed
for entering moves. I even reproduced the problem with JavaScript completely
turned off.

Please note that the two links you posted will change during the next hours -
please use the links in the navigation bar as described in the "steps to reproduce".

I'll add a link to a reduced testcase as soon as it is ready.

I'm sorry for ranking the severity of this problem too high.
(Reporter)

Comment 6

14 years ago
I just found out that the problem is only exhibited with <a> tags inside the
<td>'s. When I remove all links completely, everything displays correct all the
time (but of course the interface is unusable then).

Comment 7

14 years ago
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a4) Gecko/20040914
saw it in 2 of three cases when following steps 1 to 10 from above, and undoing
the last move. Reload of the page was fixing the issue.
(Reporter)

Comment 8

14 years ago
I have now created a stripped-down version of the testcase:

Steps to reproduce:

1. go to http://3moves.net/game/demo/problem.html
2. click on the numbered links in an alternating order. Take your time, it can
take 20-30 clicks until the problem exhibits the first time

Please let me know if I can help you with something.

Comment 9

14 years ago
Andreas, this behavior is a reflow/redraw issue and I'm very much convinced this
was reported before; there are now many "wrong layout rendering" issues with
tables. So from here, I think it would be best to search for a duplicate.
I know there was a bugfile which about a month ago changed the way tables were
rendered... 

I'm changing the component
-> Layout: Tables
Component: Browser-General → Layout: Tables

Comment 10

14 years ago
In order to search for a duplicate a really minimized testcase  would be
necessary as this would allow some diagnosis. The testcase here is however good
as it gives a reproducible way to see the error, which is more than we have in a
lot of bugs.

>I know there was a bugfile which about a month ago changed the way tables were
rendered...

Hmm, we change (tweak) the way things are rendered more frequently. If this bug
is new, for instance compared to Moz. 1.7 or 1.6 it would make sense to find the
precise regression date. This would be an enormous help, even without further
reducing the testcase.
(Reporter)

Comment 11

14 years ago
I just tried the following milestones:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 ==> not
present
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 ==> present
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 ==> present

The milestones were the only versions I can find for download, where do I get
the intermediate versions? Preferably without installer, just unzip the binaries.

I'm not sure how to further minimize the testcase. It has pretty much everything
that it needs in order to work. Please give me some hints.

Comment 12

14 years ago
> I'm not sure how to further minimize the testcase. It has pretty much everything
> that it needs in order to work. Please give me some hints.

Your stylesheet has 375 declarations and 147 rules (not to mention of at least
81 inline style declarations on top of all this!): it's utterly obvious your
layout and page is over-constrained and uses excessive and redundant css coding.

Hints:
- right now, the 81 inline style declarations for background-color of cells
might not play any role in the layout problem. Trying to minimize the current
page would remove these declarations, incrementially, one by one until "cutting
away any more (HTML or CSS) causes the bug to disappear"
- for sure, 90% of all css declarations and css rules in your
http://3moves.net/layout/standard.css
have very likely, most likely nothing to do whatsoever with the layout problem.

What is a Simplified Test Case, and How Do I Make One?
http://www.mozilla.org/newlayout/bugathon.html#testcase

Creating a reduced testcase does not need to be an 9x9 chessboard; a 5x5 might
be even more easy to do, more helpful to investigate, more easy to test, to fix.

The general rule for creating a reduced testcase is to remove anything and
everything that does not participate in the bug.

FWIW, the layout bug (empty-cells shifted, offset to the right) still happens in
Mozilla 1.8a5 build 2004100105 under XP Pro SP2. It has to be a reflow, a redraw
bug somewhere.

----

Generally speaking, your external stylesheet is not optimized, not compact,
over-constrained too. It is in your best interest to simplify and to optimize
all your CSS code here for hundreds of reasons.

Resources on that:
1- Tips for style sheet perfection (organize, combine, compress, consolidate,
rely on default browser values, inheritance of css, initial value). 

http://www.richinstyle.com/masterclass/perfection.html

eg: your style sheet gives  
body {
	margin: 0px;
	padding: 0px;
	font-family: Verdana, Arial, Geneva, sans-serif;
	font-size: 12px;
	text-align: left;
}
and it could be entirely removed. There is no need to remove browser default
margins for body (and padding in Opera 7.x); for all ltr languages, the default
text-align value is left so there is no need to define text-align: left.
font-size just needs to be set as 100% otherwise not at all; for column and row
headers of the chess board, you could simply use
th {font-size: 12px;}

2- Writing Efficient CSS: rules for optimizing CSS files
http://www.mozilla.org/xpfe/goodcss.html
(Reporter)

Comment 13

14 years ago
Thanks for your hints, Daniel!

I have now stripped the stylesheet to a minimum (4 rules) and included it in the
head of the testcase.

I also managed to get rid of the shadow while still exhibiting the problem from
time to time.

However, with any further minimized testcase (stripped labels, reduced the size
of the board, removed the links embedded into the board) I could not reproduce
the problem any more on my production system. Strangely, on my (non-public) test
system it seems to appear more often. It also seems as the smaller the file, the
less often the problem appears.

Comment 14

14 years ago
> I have now stripped the stylesheet to a minimum (4 rules) and included it in the
> head of the testcase.

My previous post had 2 aspects, 2 groups of hints: 1 was about creating a
reduced testcase exhibiting the bug in the Mozilla browser. The other aspect,
detailed after the "----" separation in my previous post, was to make your
webpage use optimized, non-redundant, compact code and that was regarding your
webpage solely.

> However, with any further minimized testcase (stripped labels, reduced the size
> of the board, removed the links embedded into the board) I could not reproduce
> the problem any more on my production system.

I still see the bug when I click links 4 or 5 or 6 at the given url with Mozilla
1.8a5 build 2004100504.

In your local stylesheet, you have:
table img { width: 25px; height: 25px; display: block; /*...*/}
Can you explain why you make images not display as inline elements?

In your file, for the purpose of creating a reduced testcase here, can you
remove one by one these elements or attributes or css declarations:
<div class="game_board">
class="chessboard"
class="label"
table img {margin: 0px; padding: 0px;}
table {table-layout:fixed;}
table {border-collapse: collapse;}
table td { margin: 0px; }

We are still in the process of creating a reduced testcase here.
The way you coded your markup code, there might be no need at all to have
styling for table tr and table td actually: the cells won't require more than
needed to render content (25x25) to start with.
You can make parsing faster and more reliable with 
td { ... }
instead
table td { ... }
Whiteboard: DUPEME
(Reporter)

Comment 15

14 years ago
> The other aspect, detailed after the "----" separation in my previous post,
> was to make your webpage use optimized, non-redundant, compact code and that
> was regarding your webpage solely.

Thanks for these hints, too. For the moment I am focused on fixing this problem
so optimizing my web page will have to wait a bit. But I will not forget!

> In your local stylesheet, you have: table img { width: 25px; height: 25px;
> display: block; /*...*/}. Can you explain why you make images not display
> as inline elements?

Because inlined images are - at least on gecko - aligned to the text baseline,
leaving some pixels of space below. Since I need images to fit seamlessly, I
choose the block display-mode.

<div class="game_board"> - done.

class="chessboard" - not yet (problem with JSTL conditional tags )-: ).

class="label" - done. This time, I was able to remove the whole label cells
while still being able to reproduce the problem.

table img {margin: 0px; padding: 0px;} - done.

table {table-layout:fixed;} - done.

table {border-collapse: collapse;} - if I switch this to "separate" (either by
inheriting the default or by explicitly specifying), I can't reproduce the
problem any more. At least it seems we have found a workaround that I can use
for my productive pages.

table td { margin: 0px; } - done.

You can make parsing faster and more reliable with 
td { ... }
instead
table td { ... } - done (for the testcase).

Comment 16

14 years ago
 
> Because inlined images are - at least on gecko - aligned to the text baseline,
> leaving some pixels of space below. 

I never heard about baseline/pixels left below; I'm not insinuating you're wrong
when saying that. The thing is that by definition, 
"When rendered visually, block-level elements usually begin on a new line."
http://www.htmlhelp.com/reference/html40/block.html

"Inherent in this structural distinction is the idea that block elements create
'larger' structures than inline elements.
Formatting
    By default, block-level elements are formatted differently than inline
elements. Generally, block-level elements begin on new lines, inline elements do
not."
http://www.w3.org/TR/html4/struct/global.html#h-7.5.3

http://www.w3.org/TR/CSS21/visuren.html#propdef-display

What you do is counter-productive: you first change the default display of
images (in order to workaround a problem) and then you try to neutralize
everywhere the visual effects of a block box when the real problem to begin with
is vertical-alignment of an inline element within a table cell. What's wrong with 
vertical-align: bottom
    "Align the bottom of the aligned subtree with the bottom of the line"
http://www.w3.org/TR/CSS21/visudet.html#propdef-vertical-align
if set in a css rule? I have not checked any of this but I sure would look into
removing that odd, awkward display: block and other related hacks to neutralize
the effects of "block-level" <img>.

Since I need images to fit seamlessly, I
> choose the block display-mode.

> table {table-layout:fixed;} - done.

It would be best to code your chessboard table to use table-layout: fixed;: you
would not only save on HTML coding and CSS coding but generally speaking, the
table would be rendered faster too and more consistently since the table
has/should have a fixed width and each column and cell has a fixed width. This
comment is for your webpage, not for the testcase here.

> table {border-collapse: collapse;} - if I switch this to "separate" (either by
> inheriting the default or by explicitly specifying), I can't reproduce the
> problem any more.

There are many bugs related to border-collapse: it is in the process of being
fixed (I hope). The thing is that you don't need at all to resort to the
border-collapse model since there is no borders between cells to begin with.
What's wrong with 
<table border="0" rules="none">
"Setting border="0" implies frame="void" and, unless otherwise specified,
rules="none"."
http://www.w3.org/TR/html4/struct/tables.html#adef-rules
border-spacing is NOT supported by MSIE 6; cellspacing="0" or rules="none" are
better supported by more browsers. You may use both border="0" rules="none" and
border-spacing: 0px to support a wider range of browsers but I would not use
border-collapse: collapse; since this is not optimally coherent, logical.

I want to warn you that we may be doing all this for nothing since there are
many reproducible bugs filed, confirmed and assigned right now on table layouts
at bugzilla. But making your table code more consistent, compact, optimal,
lighter, leaner in the process will make a difference in other areas.

Comment 17

13 years ago
> Because inlined images are - at least on gecko - aligned to the text baseline,
> leaving some pixels of space below. 
this is the most frequent bug 22274
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 19

12 years ago
Is the testcase still available somewhere?
http://3moves.net/game/demo/problem.html is 404
Following the steps in comment 0 worksforme.

Comment 20

12 years ago
Because of comments #17 and #19, I'm resolving this bug as WORKSFORME.

Andreas, you may find help at this precise url:

Images, Tables, and Mysterious Gaps
http://developer.mozilla.org/en/docs/Images%2C_Tables%2C_and_Mysterious_Gaps
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.