Closed Bug 2904 Opened 21 years ago Closed 20 years ago

Widths of cells containing images not calculated correctly


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

Windows NT





(Reporter: cpratt, Assigned: buster)




(Whiteboard: [testcase]


(3 files)

There are small red half-circles on this page. Communicator 4.51 and IE 4 draw
the text to the right of these half-circles; Raptor is drawing the text on top
of these circles. As far as I can tell these half-circles (icenter2.gif,
iresources2.gif, etc.) are in table cells that don't contain the text drawn over
them ("Datek offers access to..." etc. in the source code).
per leger, assigning QA contacts to all open bugs without QA contacts according
to list at
Target Milestone: M7
Moving to M7.
Moving to M9.
Whiteboard: [MAKING TEST]
Closed: 21 years ago
Resolution: --- → WORKSFORME
Whiteboard: [MAKING TEST] → [TEST CASE] No such problem on specified webpage. (Build 1999062113)
I'm still seeing the problem at I've also copied the files in
question to an internal Netscape server, and the problem can be seen there as
well. Look for a graphic image called visitoroff1.gif - it has text that reads
"Visitors Center". To the rigth of it is a red half-circle (visitoroff2.gif). In
4.61, the red half-circle is fully visible. In the 1999062808 build of apprunner
under NT, the image is obscured. Reopening, clearing resolution.
Resolution: WORKSFORME → ---
Whiteboard: [TEST CASE] No such problem on specified webpage. (Build 1999062113)
Whiteboard: [MAKINGTEST]
Whiteboard: [MAKINGTEST]
This is a bug with native widgets. If you switch the gfx-rendered widgets, the
image is no longer hidden.
Whiteboard: [MAKINGTEST]
My last comment is incorrect.

If I go load, the red semicircle is hidden. But if I reload the page,
the page resizes itself properly. It doesn't matter whether or not gfx widgets
are turned on.
Whiteboard: [MAKINGTEST] → [testcase]
Attached file minimal testcase
*** Bug 4481 has been marked as a duplicate of this bug. ***
*** Bug 4481 has been marked as a duplicate of this bug. ***
*** Bug 4576 has been marked as a duplicate of this bug. ***
Attached file Testcase; revision 3
Summary: Text drawn over images in adjacent table cell → Widths of cells containing images not calculated correctly
I've gone ahead and marked several bugs as duplicates of this one. All that is
needed to reproduce any of these bugs is any table that meets the following

- There must be another table nested within one of the cells. The width of this
table doesn't matter.

- There must be an image in the other cell. The width of the contents of this
cell are not used correctly. The table code does not use the correct widths of
images on the first load (but does on succeeding loads).

(Note: Bug 4576 is similar but not a dup. My latest attachment actually belongs
with bug 4576. Sorry.)
Assignee: karnaze → kipp
Target Milestone: M9 → M10
The 1st two attachments look ok. I can't load the urls due to the service
manager crashing (I am filing a bug). The 3rd attachment's right border is not
showing up. The following simplification from the 3rd attachment illustrates
that although the table cell's area frame is consistent with the table frames,
it contains a line that is too wide. I'm afraid to spin off a new bug, since so
many bugs have been marked as duplicates of this one. Reassigning to Kipp.

<TABLE cellspacing=0 cellpadding=0 border>
  <TD><div style="border:10px solid green;width:100%">x</div></TD>
Closed: 21 years ago20 years ago
Resolution: --- → INVALID
When you specify a width of "100%" for block elements you are saying that the
*content area* should be 100% the size of the parent (this is essentially the
same affect as "auto" by the way - assuming zero borders/padding). Given that
the div elements in the 3rd testcase have a border, you end up with a cropped
border because the table cell's size is *not deterministic*.

Let me explain furthur:

During the first pass of reflow of the table cell, it comes back with a size of,
say, 100. During the second pass reflow we give that "100" to the div element.
The div element's *content area* is 100 and then we add in the 10 pixel per edge
borders for a grand total of 120.

Now the table gets back an answer of 120 during the second pass!

If the table code tried to cope with this, by reflowing again, we end up in a
loop. 120 gets passed in and again we would add in 10 per side ending up with
140. And so it goes.

I've marked the bug invalid because the last testcase isn't actually a bug.
Also, the original test page now works dandy.
Closed: 20 years ago20 years ago
Resolution: INVALID → FIXED
If the original test case now works, that's a mystery fix, so I'm going to
reopen, mark this as fixed, and then verify it as such.
Verified fixed in the 1999090208 build, Windows 98.
You need to log in before you can comment on or make changes to this bug.