On Linux (only) the background color of the second row of the table appears to extend about 2 pixels beyond the left and right side of the table. May be a duplicate of #3039

I see a problem on Win32 with the upper right edge extending out too far. Later.

chrisd, is the an ALL platform, or just Linux. Please update platform if an ALL bug.

Tested using 5/4 Apprunner. Bug is cross platform. Updated to reflect.

Moving to M9.

I'm checking this with M7 under Win98. The problem is not in the second row, the second row is the image map. The problem is that the edges of the table are made of two images, both of which have fixed height. The extra pixels are occuring because the content of the table is layed out so, that it is rendered taller. I have to measure which part got bigger before I can say more about this.

Ok. I have this. First the testcase: --- <table border><tr> <td><form><input><input></form></td> <td>thisisaverylongtextcontentwithoutbrakesjusttofillupthisspace</td> </tr></table> --- Resize the viewport, so it's narrower than the desired size of the table. Mozilla breaks between the two <input> fields. Netscape 4.x doesn't break until the viewport gets narrower than the left cell of the table. Internet Explorer never breaks between the fields. I can't resist to point out that the Netscape 4.x behaviour is INSANE. IE4 is more consistent, and implementing it's behaviour would still fix the problem. Quirks. Quirks. Quirks.

This comes from bug #4427: The behaviour is NOT form related. Use <td><img src="someimage.gif"><img src="someimage.gif"></td> in my previous testcase, and you get the same behaviour. The two images behaves exactly the same, so I'll mark that bug a duplicate of this.

On windows, bloomberg looks bad because (1) the text fields at the top are too wide inside a fixed width table and (2) what the attachment points out. Steve, if this is not yours, please reassign to Kevin. When (1) gets fixed, please reassign to Kipp to fix (2), since the line's max element size must be narrower than it should be to be Nav4.6/IE5 compatible. I agree that we do not want to mimic Nav4.6 when the viewport gets very narrow. IE5 appears to be consistent given how it handles the cases when the viewport is wider.

kevin: this page lays out identically with gfx or native text controls. so I think this is in the general text/form frame layout code. reassigning to you.

Rod, here is a height/width sizing problem with gfx-text controls.

Changing to M12

Changing to M12

Fixed - The form control was not sizing correctly in NavQuirks, that has now been fixed.

Tested using 11/16 build. Verified fixed.