Looks like a table problem. The large table column is being drawn at underneath the first column?

Moving to M8.

'fool.com' is serving different content to 5.0 and 4.5. I've attached the 4.5 content to this page for a consistent point of comparison; the attachment does demonstrate the reported 'reflow of tables' problem. (jun23 win95 viewer). Marking that bug #3688 '[META] content site userAgent sniffers don't respect mozilla/5.0 user agent' has a dependency on this bug.

Simplifying the HTML tends to eliminate the problem, so I can't make a simple example. The gross structure of the page is composed of seven, self-contained, independent (non-nested) tables: <table width=600> <table width=600> <table width=600> <table width=120 align=left height=1080> ** floater <table width=350 align=left height=1060> ** floater <table width=130 align=left height=1060 valign=top> ** floater <table width=598> which should layout as: +-TABLE-600px------------------------------------------+ +-TABLE-600px------------------------------------------+ +-TABLE-600px------------------------------------------+ +-TABLE-120px-+ +-TABLE---------350px--+ +-TABLE-130px-+ +-TABLE-598px------------------------------------------+ What happens is that, as stated previously, the 350px and 130px get reflowed below the 120px table. Note that these two tables are sometimes loaded into the correct position; however, usually, waving the mouse over the <a href>s on the page for a while can get the two tables to suddenly jump to their new location (win95 jun23 viewer). So, the tables themselves are structurally OK; the problem is with the layout of the floated tables.

This issue still occurs in the June 30th builds (Mac, Win 95, Linux)

Moving to M9.

Moving to M10.

*** Bug 14029 has been marked as a duplicate of this bug. ***

Spoke to karnaze during bug triage today. Moving to M11. Not an M10 blocker.

The url and 1st attachment look ok. Resizing the 2nd attachment smaller gives different behavior than Nav4.6 and involves floating tables. Kipp, you can decide if this is compatibility bug.

This behavior is correct and in conformance with css2 desired behavior with floaters. Unlike navigator where content will always be placed next to a floater, even if that content fits, css2 defines a collection of rules that prevent overlap of content with floaters and floaters with other floaters.

Based on Kipp's comments, marking as verified invalid.

*** Bug 17360 has been marked as a duplicate of this bug. ***