User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 ( .NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 ( .NET CLR 3.5.30729) The tables are all way off to the right. Firefox is the one and only browser I've seen with this problem, so I assume the problem is with Firefox and not with the CSS code. I confirmed that this problem still exists in version 3.7a5pre. Reproducible: Always Steps to Reproduce: Simply visit the URL.

Behaves different in any other browser

If I give the float 'line-height: 1' it behaves as you expect (though even then I don't think it's a safe assumption that it should). With line-height: normal (which is the font's normal line height, generally greater than 1) this is the behavior I'd expect.

Or perhaps the difference is that other browsers are checking the space below the margin-top of the table?

Hmm. The spec requires the border box of the table to not overlap the float, but doesn't say anything about the margin box not being allowed to overlap. I think the issue is that even after fixing bug 478614 the table's margin is on the _inner_ table, not the outer. As a result, the code that handles placement next to the float scoots the _outer_ table (whose border-box in fact would overlap the float) over to the right. Can we just put the table margin on the outer table instead of the inner table?

(In reply to comment #4) > Can we just put the table margin on the outer table instead of the inner table? Would this fix bug 87277 as well?

Possibly. I won't pretend to understand the margin-c code. ;)

(In reply to Boris Zbarsky (:bz) from comment #6) > Possibly. I won't pretend to understand the margin-c code. ;) Table margins will be put on the outer table frame in bug 659828. This will fix bug 87277. In a try build with bug 659828's latest patch, this issue is fixed as well. There are similar issues like bug 543070 or the testcase in bug 105520 comment 47, however, those seem to be part of bug 25888 and won't be fixed by bug 659828.

This bug is now fixed. This is the reftest.

Try run for 5f5ead90bfa5 is complete. Detailed breakdown of the results available here: https://tbpl.mozilla.org/?tree=Try&rev=5f5ead90bfa5 Results (out of 48 total builds): success: 46 warnings: 2 Builds available at http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/eakhgari@mozilla.com-5f5ead90bfa5

This is marked as needing documentation but I'm not sure what needs to be said. Anyone have a summary of what this change is that's human readable?

(In reply to Eric Shepherd [:sheppy] from comment #11) > This is marked as needing documentation but I'm not sure what needs to be > said. Anyone have a summary of what this change is that's human readable? If you've documented bug 87277, there's nothing more to do here.

This isn't the bug I'm looking for.