User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6 When attempting to browse this page with Firefox, the table on the right covers some of the page text making it impossible to read the article. This could be a problem with Gecko as I experienced exactly the same problem with Google Chrome. In the past I have experienced similar problems with Thunderbird derivative, Eudora 8 beta. In that case HTML email received via Yahoo Groups are not readable because the Yahoo advert on the right covers the text. Imagine the embarrassment of having to switch to IE because Firefox can't display a page properly. IE does display the submitted URL correctly. Reproducible: Always Steps to Reproduce: 1. Just visit the above URL 2. 3.

This is part of the page how I see it with the latest Firefox 3.0 on Windows XP: http://img152.imageshack.us/img152/8567/pagetc3.jpg I see no problem at first glance. Can you point out the problem / retest in safe-mode / retest with a new profile? http://support.mozilla.com/en-US/kb/Safe+Mode http://support.mozilla.com/en-US/kb/Basic+Troubleshooting#Make_a_new_profile

This is how I see the page with Firefox 3.0.6. Note that the page text is covered by advertisements on the right.

This is how I see the page with Firefox 3.0.6. Note that the page text is covered by advertisements on the right.

The problem seems to be related to the Google Sponsored links table. On your page the sponsored links is on the right. On my page it is on the left with the page text to the right of it. On IE it is on the left with the page text under it.

Reporter, can you still reproduce the issue with the latest Firefox build and a new profile? I see no issues on the page, tested on Windows. http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/ http://support.mozilla.com/en-US/kb/Basic+Troubleshooting#Make_a_new_profile

Yes I still get the same problem when I visit the page with Firefox 3.5.3

I have attached an image of the page viewed with IE. Note that the page text (magenta mark) starts below the advertisements on the left. (red mark)

Here is how the page looks in Minefield. Note that the page text (magenta mark) starts on the right of the left advertisement (red mark). As a result the advertisement on the right (red arrow) covers the page text. This is exactly how this same page looks in Firefox 3.5.3, Google Chrome and now Minefield. I am no expert but my guess is that it could be a problem with Gecko.

Note that on your image posted here http://img152.imageshack.us/img152/8567/pagetc3.jpg, the sponsored text appears on the right of the main page text with the other advertisement below it. On my PC the advertisement and the sponsored text are on opposite sides of the page and this could be the source of the problem.

This is a mass search for Firefox General bugs filed against version 3.0 that are UNCO and have not been changed for 200 days. Reporter, please update to Firefox 3.6.10 or alter. Firefox 3.0 is no longer supported and is no longer receiving updates. After you update, please create a fresh profile, http://support.mozilla.com/kb/managing+profiles, and test to see if your bug still exists. If you still the bug, then please post a comment with the version you tested against, and the problem. If the issue is no longer there, please set the RESOLUTION to RESOLVED, WORKSFORME.

The problem as seen on my computer still hapens.

The problem is still happening with "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10 ( .NET CLR 3.5.30729)"

The bug was also observed with Minefield 4.0b7pre

I can confirm this, using mozilla-central trunk (making sure to disable Adblock Plus) Mozilla/5.0 (X11; Linux x86_64; rv:2.0b7pre) Gecko/20101006 Firefox/4.0b7pre I tried Opera 10.62, and the bug doesn't manifest there. (though that doesn't necessarily mean anything, as there could be browser-sniffing going on)

I'm not convinced this is a Table bug -- shifting to just "Layout" component. So there are two ad bars in play here -- one on the left (id="sidebar"), with "sponsored links", and one on the right (id="widgets"), with "Free Delphi Programming Newsletter!" I played around with this a little in DOM Inspector -- I don't think it's actually the right ad bar that's necessarily at fault. Part of the blame seems to belong to the left one, which ends up pushing the content out of the way & under the right ad bar. A few notes, from deleting/tweaking things in DOM inspector: - If I delete the left ad bar, then everything is fine. - If I delete the right ad bar, then everything is fine. - If I delete the right ad bar **and position the left ad bar on the right** ( by adding the attribute style="float: right" to it, overriding its "float: left" computed style), then it obscures page content. A reduced testcase would be useful to find out more here. Martijn, would you mind reducing a testcase that's broken (has a sidebar overlapping main content) in Firefox but works in Opera and/or IE?

Chromium matches the Opera & IE rendering, FWIW (shown in attachment 400326 [details])

The issue appears to be the text being pushed right by the left sidebar. Other browsers display the text underneath the sidebar and wrap at the div boundary.

Nice job, Ryan! Observations: - In Nightly, the table (containing all the "CONTENT THAT etc" text) is positioned to the right of the floated element, and it sticks outside of its green container-div. - In Opera 11.61 & Chromium 16.0.912.77, the table is positioned *below* the floated element (presumably because it can't fit to the right without overflowing), and its text is all inside the green rect. The Opera & Chromium behavior seems sensible/correct.

So is this basically a duplicate of bug 653355 (which is itself a dup of an earlier bug, and not of this one).

Setting dependency on bug 653355, then, to make it more likely we'll remember their connection once one of them finds the right dupe-target. :)

My primary concern is that this is a bug that clearly affects real sites, yet hasn't gotten any attention for at least 3 years (likely longer if there's an earlier bug to dupe to). My experience with bug triage is that adding a DUPEME to the whiteboard is basically inviting it to be forgotten about. My wish would be to see it fixed here and if the earlier bug is found, duped forward to this one.

It's not trivial to fix, nor is it obvious what the right behavior is, which is why it's still not fixed....

The correct behavior is clearly described here: http://www.w3.org/TR/CSS2/visuren.html#floats Essentially, proper behavior is as seen in the other browsers at this time; if a block (either by width setting or by the force of its content) is too large for the horizontal space available between the edge of the floated item and the container's edge, the block should be moved down to the next line. With regard to my particular instance of this problem (Duplicate of this bug, 728291, just added): From what I have seen, it is connected to the use of h2 (and possibly some other distinct elements), rather than a general float problem. This example (http://jsfiddle.net/ugTxs/8/) shows that use of h3 does not exhibit the same erroneous behavior (nor do h's 1, and 4-6 by my testing). Moreover, this example (http://jsfiddle.net/ugTxs/7/) reveals that for some reason the floated h2 is being considered part of the same block as the elements that follow it; note how the div's border is actually encapsulating the h2 as well, despite the two elements being neighbors rather than parent-child. By my tests this is also specific to h2 only. Because of this, it seems the float is being applied to the conglomerate h2-div block interpreted by the engine. In actuality the code hasn't specified such an element, but that is the scenario that would result in this behavior. I encourage someone to take a look at what's so special about h2, even if it's just a matter of the differences in default styles for the various heading tags, and investigate why its float property is being propagated to its neighbors. I would not be surprised if at least this specific case is a more trivial fix than might have been expected.

Note that we do wrap the table around the float if the table lines up with a point below the top of the float (e.g., if the table has a div with height 1px before it, but after the float). I think this is closely related to the remaining (block) parts of bug 25888 (for which I have some work-in-progress in my tree, and have for years), which should probably be split into a separate bug (maybe even this one).

This affects "display:flex" in the same way that it affects "display:table", FWIW, and it's why we currently fail this opera-submitted flexbox test: http://hg.csswg.org/test/raw-file/af50541e57c4/contributors/opera/submitted/css3-flexbox/flexbox_fbfc.html (reference case: http://hg.csswg.org/test/raw-file/af50541e57c4/contributors/opera/submitted/css3-flexbox/flexbox_fbfc-ref.html ) In investigating, I found that adding "border-top" or "padding-top" on the float container seems to make the content wrap below the table. This testcase has a hover-triggered border-top, to demonstrate that.

(In reply to tjfortier from comment #26) > This example > (http://jsfiddle.net/ugTxs/8/) shows that use of h3 does not exhibit the > same erroneous behavior (nor do h's 1, and 4-6 by my testing). That's because you only styled h2 to float. There's nothing special about it.

Common somebody should work on this. Its a bug since 2009. The following page shows the bug with the correct output beneath it http://jsbin.com/bewane/2/

For what it's worth, the current state of my patch for the block part of bug 25888 (which has some reftests in the tree already) is: https://hg.mozilla.org/users/dbaron_mozilla.com/patches/raw-file/fce93660c59b/float-redo-for-blocks (We should probably resolve bug 25888 as fixed for the inline part of the bug and move the relevant block dependencies to another bug, maybe this one.) That said, fully fixing bug 25888 for blocks I *think* may go beyond what other browsers do, and might have some compatibility risk. That said, it's probably still doable, so it may well be reasonable to do in this bug. I also have basically-empty patches related to bullets which should probably be a third bug: https://hg.mozilla.org/users/dbaron_mozilla.com/patches/raw-file/fce93660c59b/bullet-propagate-to-descendant https://hg.mozilla.org/users/dbaron_mozilla.com/patches/raw-file/fce93660c59b/float-redo-for-bullet

(In reply to David Baron [:dbaron] ⏰UTC-7 from comment #37) > That said, fully fixing bug 25888 for blocks I *think* may go beyond what > other browsers do, and might have some compatibility risk. That said, it's > probably still doable, so it may well be reasonable to do in this bug. By this I mean: * we currently indent BFC-creating blocks or (if they no longer fit) move them down when the top pixel of the block is adjacent to a part of a float other than its top pixel. * the site bugs we see here are about when the top pixels of both are lined up with each other; we do the indenting but not the moving down because they don't fit * per spec, we should really indent a block or (if it doesn't fit) move the block down when any parts of it are adjacent to a float So on second thought, this bug might actually be pretty unrelated, since we *are* pushing the block out of the way horizontally; we just aren't pushing it down when it doesn't fit. (This might be related to margin collapsing somehow.)

[Clearing stale "DUPEME" added in comment 21; the bug suggested as a dupe-target around there was later duped to this bug.]

(meant to say: Expanding summary, per bug 1073574 comment 8)

NI:me to huddle with the experts on this one. As it happens, we're about to carve into tables and flexbox to support vertical text. What can we do for this bug while we're in there?

(In reply to Jet Villegas (:jet) from comment #44) > As it happens, we're about to carve into tables and flexbox to support vertical text. > What can we do for this bug while we're in there? (As I understand it, this is a bug in our float layout code, rather than in our table/flexbox/etc. code.)

I'll try to dig into this next week.

So it looks like in Chrome, bug 25888's case for blocks is fully fixed; lining up at the top isn't required. (Note that if I add enough additional "L" floats at the start of this testcase, the float pops back up because it fits.)

Without this change, nsBlockFrame::ReflowBlockFrame will fail to have mayNeedRetry true, which means that it won't set blockHTMLRS.mDiscoveredClearance, which means that on a descendant replaced block we will fail to fall into any of the cases that call ClearFloats. This change will cause us to hit the first ClearFloats call and discover the need for clearance. I tested locally that the new reftest fails without the patch and passes with the patch.

Note that I didn't attempt to fix bug 25888 for blocks here, although I have had a half-done patch for that in my tree for years.

Added the site compatibility doc: https://www.fxsitecompat.com/en-US/docs/2015/css-float-bugs-have-been-fixed/

Added a brief note here: https://developer.mozilla.org/en-US/Firefox/Releases/42#CSS