RedHat 5.2, 2.0.36 kernel, fvwm The top of the intel page has a tab-like image that spans most of the page. With the Feb04 viewer on other platforms and with IE & Navigator 4.x, it looks normal. With the Linux build, though, there's a space between the image's two rows (the upper one says "contents | search | contact us | support" and the lower reads "Home computing | business computing | product info.") It looks like there's a partial image at the left end of the gap, and the "intel" logo that appears at the right side of the image is laid out crooked. Overall, it justs looks wrong.

Platform parity, it sounds like, so adding [PP] to summary.

Looks fine to me under NT, and there's no indication of which platforms it displays correctly on and which it doesn't All of layout is XP, so if it's wrong on only one platform then it's probably not a layout problem

The platform it was reported against (see above) is Linux. The "other platforms" in the original description refer to Windows (95) and Mac (8.1), so it's not at all surprising that it looks normal to you on your NT box. If it's not layout, please change the component. I'm helping out the browser group by writing obvious bugs for 5 chosen sites, and I have no idea what component to make it. If you've a better guess, please change it. Reopening.

Clearing resolution.

No, I have way too much to do to process bugs for QA. You guys need to properly narrow the bug down

eli or beth - if you have a better idea of the correct component and/or engineer for this bug, pls reassign and change. Thanks.

Changed Component category to HTMLTables. Also, bug is now narrowed down and isolated to the above URL (http://slip/projects/marvin/bugs/intel4_bug.html). In isolated version, there is one table with 2 rows and each row has two columns. The table has a width of 582 pixels and contains 10 images. 1st row, 1st column: row width = 484 and contains 5 images with widths of 112, 102, 123, 104 and 43 (total of 484). 1st row, 2nd column: row width = 98 and contains 1 image with width of 98. 2nd row, 1st column: row width = 470 and contains 3 images with widths of 170, 180, and 120 (total of 470). 2nd row, 2nd column: row width = 14 and contains 1 image with width of 14. Expected result: The images should fit within the specified widths of the columns and within the table width. Actual result: In Linux, the 'curveone.gif' appears not to fit in specified width and wraps to next line. Reopening bug.

changing QA contact to chrisd@netscape.com

Were this not just on Linux, I'd think it would be a duplicate of 2954 ["Last image in this table row doesn't fit in table row (drawn below)"] But, it's probably related.

Reassigning to Ramero since it is linux only.

I just tried this on apr 6 builds of both nt and linux. Both look almost identical. However, they both dont look like 4.5. The table that www.intel.com is using at the top of their site is not laying out as they expect on gecko. So, it seems to me this is an XP 4.5 compatibility table layout issue. A low priority thing at this time, I would think. It would be useful if someone in QA could isolate a test case locally. Reassigning back to karnaze@netscape.com.

changing os to all

Moving to M8.

Could someone please attach the test case to this bug so that we can see it from outside the Netscape intranet? Thanks!

Apparently an image in a link with a border set to 0 still makes a space for a border. coder@geocities.com . . . on my way to getting that gecko doll =)

The behaviour visible in the second test case is actually correct and is a duplicate of bug 5821. It is nothing to do with border=0, it has a lot to do with the inline box model of CSS2 (see bug 5821 for a detailed analysis). I would tentatively guess that the bug at intel is actually the same thing. I cannot easily check it now, but to see if the problem is the same on the intel page, add the following after the <TITLE></TITLE> line: <BASE HREF="http://www.intel.com/"> <STYLE TYPE="text/css"> IMG { vertical-align: bottom; } </STYLE> ...then save the file locally and open it in Mozilla. If the problem goes away, then mark this bug as a duplicate of bug 5821.

Moving to M9.

Yes, another duplicate of bug 5821. *** This bug has been marked as a duplicate of 5821 ***

Verified Duplicate