Closed Bug 3929 Opened 26 years ago Closed 26 years ago

Tables: Disparities between debug and optimized builds

Categories

(Core :: Layout, defect, P2)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: pierre, Assigned: buster)

Details

Reproduced with today's debug and optimized builds on Mac and Win32. - Display Test6 on a debug build: it's correct. - Display Test6 on an optimized build: the rendering of the center cells of the top table is not correct (blue background instead of green, some cells are missing)
A screen snapshot is on http://pierre/bugs/bug3929test6.jpg
Status: NEW → ASSIGNED
I'll ask Steve about this before I try to fix it. He recently fixed a problem where optimized/debug builds were different.
Assignee: karnaze → buster
Status: ASSIGNED → NEW
Priority: P3 → P2
Summary: Test6: Disparities between debug and optimized builds → Tables: Disparities between debug and optimized builds
The problem is still here with today's build on Mac and Windows. It also happens on http://www.mozilla.org/party/1999/ Steve, could you give us some details about the problem you fixed where optimized/debug builds were different and then reassign to <karnaze>? Thanks.
Status: NEW → ASSIGNED
Looking into it...
On first look, these both appear to be parser bugs. It looks like nested tables are getting closed early, in optimized builds only :( I'm doing more work now to try to get minimized test cases.
Assignee: buster → rickg
URL: see test case
Status: ASSIGNED → NEW
Here is a somewhat smaller test case, derived from sample 6. Cells are named to clearly show the parser (or possibly content sink?) is not operating correctly. This only happens in optimized builds. Debug builds are fine. I have only tested on Windows, so I don't know how other platforms are effected, though Pierre added comments that Mac optimized only is also broken. The test case is still rather large. Any change to it at this point seems to result in correct layout. It's as if the depth of nesting is somehow significant. <html><body> <table border=1 bgcolor=red> <TR> <TD>Cell1 a</TD> <TD> <table border=1 bgcolor=lightblue> <TR> <TD>Cell1 b</TD> <TD> <table border=1 bgcolor=lightgreen> <TR> <TD>Cell1 c</TD> <TD> <table border=1 bgcolor=yellow> <TR> <TD>Cell1 d</TD> <TD> <table border=1 bgcolor=orange> <TR> <TD>Cell1 e</TD> <TD> <table border=1 bgcolor=red> <TR> <TD>Cell1 f</TD> <TD> <table border=1 bgcolor=lightblue> <TR> <TD>Cell1 g</TD> <TD> <table border=1 bgcolor=lightgreen> <TR> <TD>Cell h</TD> </TR> </table> </TD> </TR> <TR><TD>Cell2 g</TD></TR> </table> </TD> </TR> <TR><TD>Cell2 f</TD></TR> </table> </TD> </TR> <TR><TD>Cell2 e</TD></TR> </table> </TD> </TR> <TR><TD>Cell2 d</TD></TR> </table> </TD> </TR> <TR><TD>Cell2 c</TD></TR> </table> </TD> </TR> <TR><TD>Cell2 b</TD></TR> </table> </TD> </TR> <TR><TD>Cell2 a</TD></TR> </table> </body></html>
It's a cross-platform problem. It has been verified on Mac and Windows, and I think that I've seen it on Unix too. Very often on the Mac, differences between Debug and Optimized builds come from uninitialized variables. This time, since it is a cross-platform problem, I would tend to think that it comes from some good and necessary code that is only executed #ifdef DEBUG instead of all the time.
Assignee: rickg → kipp
Kipp: I'm pretty sure now that this is a contentsink bug. I've reduced test6 to a min case which shows the errant behavior in optmized builds. I'll also throw screen grabs your way.
Severity: normal → major
Status: NEW → ASSIGNED
I can't reproduce this bug anymore. Can anyone else?
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
I can't reproduce it either. Marking Fixed.
Status: RESOLVED → VERIFIED
The June 2nd build renders the table sample correctly.
URL: see test case
You need to log in before you can comment on or make changes to this bug.