I Steps: Go to https://www.homedepot.ca/webapp/wcs/stores/servlet/AuctionHomeView?langId=-15&krypto=oTJa5EwIaYnwBXs42YJAe%2F61ZihlDu5w8Qj04zczYEtWQAU7x8BD5N4htPFd9Gp64SayyWwASYKG%0D%0A8VJQiFW%2Fog%3D%3D II Issue: In the right column: under button "Place Bid", there is an overlap of "REFRESH" and image "tell a friend" III Conclusion: #tellAFriend { float:right;} is causing the issue. removing float:right resolves the issue. IV Other browsers: IE7: ok FF3: not ok Opera9.24: not ok V Nightly tested: 31386
Created attachment 20264 [details] screenshot
Created attachment 20265 [details] reduction
Created attachment 23187 [details] simpler testcase Confirmed on Chrome. This is an annoying bug that occurs frequently on Wikipedia, see e.g. http://en.wikipedia.org/w/index.php?title=Portal:Current_events/Science_and_technology&oldid=235956298 You don't need any images or fancy positioning like in your testcase, so I attached a simpler testcase I originally made for Gecko ( https://bugzilla.mozilla.org/show_bug.cgi?id=338526#c8 ). IE7 renders it fine, but both Firefox and Google Chrome fail. The bug is being ignored by the Gecko people, hopefully it will get a better response here...
Yeah. The bug is basically that we only sample at the "top" of a line when looking for floats that affect a line. We do this since we don't really know how tall the line is going to be until we actually put stuff on it. It would be reasonable to do multiple samples (e.g., the top, middle and bottom of a hypothetical line based off the font of the block).
I take it back. The test case is something different I think.
Thanks for looking into it. Also, this looks like a duplicate of https://bugs.webkit.org/show_bug.cgi?id=15956 and https://bugs.webkit.org/show_bug.cgi?id=13698 .
What I said is still basically true. For objects that shrink to avoid floats (like tables or overflow sections), we only sample the top of the line. int RenderBox::containingBlockWidth() const { RenderBlock* cb = containingBlock(); if (!cb) return 0; if (shrinkToAvoidFloats()) return cb->lineWidth(m_y); return cb->availableWidth(); } A fix would involve special casing fixed height objects. Basically because you know the height can't change if you vary the width, you can safely test for floats that intersect from your y-position to your y-position + height. However for auto height objects you can't do that and can really only sample at your y-position. The question is whether it would be worth making fixed height objects inconsistent with auto height objects. CSS2.1 says: http://www.w3.org/TR/CSS21/visuren.html#bfc-next-to-float "The border box of a table, a block-level replaced element, or an element in the normal flow that establishes a new block formatting context (such as an element with 'overflow' other than 'visible') must not overlap any floats in the same block formatting context as the element itself. If necessary, implementations should clear the said element by placing it below any preceding floats, but may place it adjacent to such floats if there is sufficient space. They may even make the border box of said element narrower than defined by section 10.3.3. CSS2 does not define when a UA may put said element next to the float or by how much said element may become narrower."
The term "must not" is used in that paragraph, meaning this is definitely a bug.
Ok as interesting as all my comments were, none of the later stuff has anything to do with the original reported bug (an overlap of float and a positioned element). This rendering (see the first reduction) is correct and has nothing to do with wikipedia bugs. Feel free to attach your test case to the actual wikipedia bug.
Attached it to Bug 15956. Sorry for the misidentification.