216573 - {inc}cell width and height get inconsistantly miscomputated

Status: RESOLVED WORKSFORME

(Core :: Layout: Tables, defect)

Description

[Jerome Lacoste]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030714 Debian/1.4-2
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030714 Debian/1.4-2

Loading the aforementionned URL creates a badly displayed page, most of the
time. A cell within a table contained in that page has wrong dimensions. This
happens around 50% of the time.
That makes mozilla creates an horizontal bar necessary to view the content that
was misplaced to the right and a vertical bar to show the content that was
pushed to the bottom. See first screenshot.


CTRL+SHIFT+R reload the page correctly 99%+ of the time (I never saw it fail),
where I correctly see that the layout creation happens differently (images being
rendered last).See second screenshot.
When browsing the badly rendered page, if I select image inside the page (either
background or normal image) and view it, then use "back", the page is also 99%+
of the time correctly rendered (never saw it fail neither). 

Saving the page localy, and I don't manage to reproduce the problem.

The page has the following structure:

One table with 3 rows, the first for header, the last for bottom.
The second row contents the content, split into 3 cells.
The first cell is the one that has miscomputated dimensions: width 1341px height
2029px. See screenshot 3.
Something strange happens there that might be a hint: inside the DOM inspector
when selecting the aforementionned cell, the border that blinks in red spans
lower than the row the cell is supposed to be in (it spans up to the bottom of
the page).
On the other side, this can be reproduced easily when opening the DOM inspector
on the same page when saved on the disk, even if that page never exhibited the
problem to me.

Tested under 1.4 on Linux (Debian build) and Windows 98 (thanks to Chewie on
#mozillazine).

Reproducible: Sometimes

Steps to Reproduce:
1.
2.
3.

Actual Results:  
badly rendered page

Expected Results:  
correctly rendered page.

Comment 1

[Jerome Lacoste]

Attachment: Shows the problem

Comment 2

[Jerome Lacoste]

Attachment: Sometimes display correctly

Comment 3

[Jerome Lacoste]

Attachment: when cell opened in DOM, CSS style shows 150px, computed style shows 1341 px

This screenshot shows the DOM inspector opened on the URL. The cell is selected
and renders incorrectly, while its style is specfied to be 150px, but the
computed style is much larger. Note that the computer style could come from
another cell, but that's the one single cell from the table that shows both bad
width and bad height.

Comment 4

[Jerome Lacoste]

Attachment: fixed CSS that now validates

I would also like to say that the style for the page doesn't validate
correctly:
http://jigsaw.w3.org/css-validator/validator?uri=http%3A%2F%2Fwww.digitalimpuls.no%2Fcss%2FmcWeb.css&warning=1&profile=css2


I fixed the issues in the attached file.

Comment 5

[Bernd]

A valid reduced testcase (http://www.mozilla.org/newlayout/bugathon.html) would
help significantly more than any screenshot. This is due to the fact that fixing
 the table bugs is so slow that the page will definetely be changed before the
bug gets touched. Second only with a valid testcase it is possible to dupe the
bug and third as I know from my experience bugs without a testcase will be fixed
after bugs that have a testcase ( aka never).

Comment 6

[Jerome Lacoste]

I know I need a testcase, but I am not yet capable of producing one. Especially
because the problem only happens when downloading from the web. I might try to
use Hixie's uploading server to try to make a reduce test case. But that will
take me time. I already spent more than 2 hours on that one yesterday.

Comment 7

[H.Eckert]

Still in need of a test case?

Take a look at <html://www.hacking-aliens.de/uucp/>.
Unfortunately incoming spam is most likely to trigger the bug for me.

The first table shows the minimal testcase for a mail entry that is badly formatted.
The second is a change to the tablerow structure in which the renderer works
correctly.
The third is equal to the second (only internally different html formatting)
The last one shows the same table as the first with a different subject to show
that the table itself is correct.

In case it helps localizing this bug in the renderer, it worked with Mozilla 1.3.1.

Comment 8

[H.Eckert]

This should read <http://www.hacking-aliens.de/uucp/> of course.  <blush>

Comment 9

[Steve England [:stevee]]

Website in URL field has since changed (comparing it currently and from the pics attached to this bug).

Comment 10

[Mats Palmgren (inactive)]

There is a difference in rendering the URL pre/post reflow branch landing,
though I haven't analyzed which is correct.
In SeaMonkey 2006120801 on Linux the "15x" image is mostly centered
in the page, in a 2006120701 build it's more to the right.
(FWIW, Opera9 on Linux renders as 2006120701).

A reduced testcase to highlight the difference would be appreciated.

Comment 11

[Bernd]

this is wfm, what exactly is the bug here?

Comment 12

[Mats Palmgren (inactive)]

Comparing pre/post reflow branch landing once again I don't see any
difference in the rendering for the URL.  I saw a difference in comment 10
so I suspect the content have changed (again) since then.

WFM, in a current Firefox 3.1b1pre build on Linux.

-> WORKSFORME