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 http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

Moving to M7.

Moving to M9.

I'm still seeing the problem at datek.com. 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.

This is a bug with native widgets. If you switch the gfx-rendered widgets, the image is no longer hidden.

My last comment is incorrect. If I go load datek.com, 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.

*** 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. ***

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 criteria: - 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.)

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> <TR> <TD><div style="border:10px solid green;width:100%">x</div></TD> </TR> </TABLE>

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.

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.