punungwe Reporter
	Description • 15 years ago

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.

	Ria Klaassen (not reading all bugmail)
	Comment 1 • 15 years ago

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

	punungwe Reporter
	Comment 2 • 15 years ago

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

	punungwe Reporter
	Comment 3 • 15 years ago

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

	punungwe Reporter
	Comment 4 • 15 years ago

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.

	Ria Klaassen (not reading all bugmail)
	Comment 5 • 15 years ago

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

	punungwe Reporter
	Comment 6 • 15 years ago

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

	punungwe Reporter
	Comment 8 • 15 years ago

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)

	punungwe Reporter
	Comment 9 • 15 years ago

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.

	punungwe Reporter
	Comment 10 • 15 years ago

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.

	Tyler Downer [He/Him]
	Comment 11 • 14 years ago

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.

	punungwe Reporter
	Comment 12 • 14 years ago

The problem as seen on my computer still hapens.

	punungwe Reporter
	Comment 13 • 14 years ago

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)"

	punungwe Reporter
	Comment 14 • 14 years ago

The bug was also observed with Minefield 4.0b7pre

	Daniel Holbert [:dholbert]
	Comment 15 • 14 years ago

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)

	Daniel Holbert [:dholbert]
	Comment 16 • 14 years ago

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?

	Daniel Holbert [:dholbert]
	Comment 17 • 14 years ago

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

	Ryan VanderMeulen [:RyanVM]
	Comment 18 • 12 years ago

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.

	Daniel Holbert [:dholbert]
	Comment 19 • 12 years ago

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.

	Boris Zbarsky [:bzbarsky]
	Comment 20 • 12 years ago

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

	Daniel Holbert [:dholbert]
	Comment 21 • 12 years ago

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. :)

	Ryan VanderMeulen [:RyanVM]
	Comment 23 • 12 years ago

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.

	Boris Zbarsky [:bzbarsky]
	Comment 24 • 12 years ago

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

	tjfortier
	Comment 26 • 12 years ago

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.

	David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla) Assignee
	Comment 27 • 12 years ago

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).

	Daniel Holbert [:dholbert]
	Comment 32 • 11 years ago

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.

	Stijn Herreman
	Comment 33 • 10 years ago

(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.

	meghjp
	Comment 35 • 9 years ago

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/

	David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla) Assignee
	Comment 37 • 9 years ago

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

	David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla) Assignee
	Comment 38 • 9 years ago

(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.)

	Daniel Holbert [:dholbert]
	Comment 39 • 9 years ago

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

	Daniel Holbert [:dholbert]
	Comment 43 • 9 years ago

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

	Jet Villegas (inactive)
	Comment 44 • 9 years ago

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?

	Daniel Holbert [:dholbert]
	Comment 45 • 9 years ago

(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.)

	David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla) Assignee
	Comment 47 • 9 years ago

I'll try to dig into this next week.

	David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla) Assignee
	Comment 48 • 9 years ago

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.)

	David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla) Assignee
	Comment 49 • 9 years ago

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.

	David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla) Assignee
	Comment 50 • 9 years ago

https://treeherder.mozilla.org/#/jobs?repo=try&revision=4efdc8d602a3

	David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla) Assignee
	Comment 51 • 9 years ago

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.

	Pulsebot
	Comment 52 • 9 years ago

https://hg.mozilla.org/integration/mozilla-inbound/rev/c63a6810b2bb

	Carsten Book [:Tomcat]
	Comment 53 • 9 years ago

https://hg.mozilla.org/mozilla-central/rev/c63a6810b2bb

	Kohei Yoshino [:kohei]
	Comment 67 • 9 years ago

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

	Jean-Yves Perrier [:teoli]
	Comment 68 • 9 years ago

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