table (or other BFC) following float doesn't clear it even if it can't fit next to it, when lined up at their tops

RESOLVED FIXED in Firefox 42

Status

()

Core
Layout: Floats
--
major
RESOLVED FIXED
9 years ago
a year ago

People

(Reporter: punungwe, Assigned: dbaron)

Tracking

(Blocks: 1 bug, {dev-doc-complete, site-compat})

Trunk
mozilla42
dev-doc-complete, site-compat
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(p11+, firefox42 fixed)

Details

(Whiteboard: [compat], URL)

Attachments

(12 attachments)

(Reporter)

Description

9 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.
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
Version: unspecified → 3.0 Branch
(Reporter)

Comment 2

9 years ago
Created attachment 362702 [details]
Image of page showing problem

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

Comment 3

9 years ago
Created attachment 362703 [details]
Second Image showing problem

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

Comment 4

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

Comment 6

8 years ago
Yes I still get the same problem when I visit the page with Firefox 3.5.3
(Reporter)

Comment 7

8 years ago
Created attachment 400306 [details]
Image showing table on right covering page text.
(Reporter)

Comment 8

8 years ago
Created attachment 400326 [details]
How the page looks in IE

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

Comment 9

8 years ago
Created attachment 400327 [details]
How the page looks in Minefield

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

Comment 10

8 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.
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.
Whiteboard: [CLOSEME 2010-11-01]
(Reporter)

Comment 12

7 years ago
Created attachment 481308 [details]
Image showing frame covering page text

The problem as seen on my computer still hapens.

Updated

7 years ago
Component: General → Layout: Tables
Product: Firefox → Core
QA Contact: general → layout.tables
Whiteboard: [CLOSEME 2010-11-01]
Version: 3.0 Branch → 1.9.2 Branch
(Reporter)

Comment 13

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

Comment 14

7 years ago
Created attachment 481311 [details]
Bug observed wit minefield

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)
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: x86 → All
Summary: Table covers page text → delphi.about.com page content covered up by right-sidebar-ads (with heading "Free Delphi Programming Newsletter!")
Version: 1.9.2 Branch → Trunk
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?
Component: Layout: Tables → Layout
QA Contact: layout.tables → layout
Chromium matches the Opera & IE rendering, FWIW (shown in attachment 400326 [details])
Keywords: qawanted, testcase-wanted
Created attachment 594577 [details]
Reduced testcase

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.
Keywords: testcase-wanted
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.
Keywords: qawanted
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. :)
Depends on: 653355
Whiteboard: DUPEME
Duplicate of this bug: 653355
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.
No longer depends on: 653355
It's not trivial to fix, nor is it obvious what the right behavior is, which is why it's still not fixed....
Summary: delphi.about.com page content covered up by right-sidebar-ads (with heading "Free Delphi Programming Newsletter!") → table following left float doesn't clear it even if it can't fit next to it
Duplicate of this bug: 728291

Comment 26

5 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.
Blocks: 739871
(Assignee)

Comment 27

5 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).
Depends on: 25888
Created attachment 611748 [details]
Testcase from bug 739871

Updated

5 years ago
No longer blocks: 739871
Duplicate of this bug: 739871
Duplicate of this bug: 763035

Updated

5 years ago
Blocks: 817961
Blocks: 816657
(Assignee)

Updated

5 years ago
Duplicate of this bug: 833250
Created attachment 755048 [details]
testcase 3 (with hover-triggered border-top, which fixes this)

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.

Comment 33

3 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.
Blocks: 1133656

Updated

2 years ago
Duplicate of this bug: 1133656

Comment 35

2 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/
Duplicate of this bug: 1073574
Blocks: 1144461
Blocks: 1130866
(Assignee)

Comment 37

2 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
(Assignee)

Comment 38

2 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.)
[Clearing stale "DUPEME" added in comment 21; the bug suggested as a dupe-target around there was later duped to this bug.]
Whiteboard: DUPEME
Duplicate of this bug: 1152751
Blocks: 1152751
Duplicate of this bug: 1152751
Comment hidden (obsolete)
(meant to say: Expanding summary, per bug 1073574 comment 8)

Comment 44

2 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?
Flags: needinfo?(bugs)
(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.)
Component: Layout → Layout: Floats

Updated

2 years ago
tracking-p11: --- → +
Priority: -- → P3
Whiteboard: [compat]

Updated

2 years ago
Priority: P3 → --
(Assignee)

Updated

2 years ago
Duplicate of this bug: 952981
(Assignee)

Comment 47

2 years ago
I'll try to dig into this next week.
Assignee: nobody → dbaron
(Assignee)

Updated

2 years ago
Summary: table following left float doesn't clear it even if it can't fit next to it (& same for block-level img, flex container, etc. following left float) → table (or other BFC) following float doesn't clear it even if it can't fit next to it, when lined up at their tops
(Assignee)

Comment 48

2 years ago
Created attachment 8639548 [details]
variant testcase

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

Comment 49

2 years ago
Created attachment 8639611 [details] [diff] [review]
Record that we need to look for clearance if we encounter a block that might need to be pushed down for intersecting floats (i.e., one that establishes a BFC)

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.
Attachment #8639611 - Flags: review?(roc)
(Assignee)

Comment 50

2 years ago
https://treeherder.mozilla.org/#/jobs?repo=try&revision=4efdc8d602a3
(Assignee)

Comment 51

2 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.
Attachment #8639611 - Flags: review?(roc) → review+
(Assignee)

Updated

2 years ago
Flags: needinfo?(bugs)

Comment 52

2 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/c63a6810b2bb
https://hg.mozilla.org/mozilla-central/rev/c63a6810b2bb
Status: NEW → RESOLVED
Last Resolved: 2 years ago
status-firefox42: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla42
(Assignee)

Updated

2 years ago
Duplicate of this bug: 817961
(Assignee)

Updated

2 years ago
Duplicate of this bug: 349255

Updated

2 years ago
Duplicate of this bug: 641947

Updated

2 years ago
Duplicate of this bug: 1130866
(Assignee)

Updated

2 years ago
Duplicate of this bug: 14984
(Assignee)

Updated

2 years ago
Duplicate of this bug: 35478
(Assignee)

Updated

2 years ago
Duplicate of this bug: 543070
(Assignee)

Updated

2 years ago
Duplicate of this bug: 290146
(Assignee)

Updated

2 years ago
Duplicate of this bug: 653478
(Assignee)

Updated

2 years ago
Duplicate of this bug: 738926
(Assignee)

Updated

2 years ago
Duplicate of this bug: 1162946
(Assignee)

Updated

2 years ago
Duplicate of this bug: 885909
(Assignee)

Updated

2 years ago
Blocks: 884468
(Assignee)

Updated

2 years ago
Duplicate of this bug: 1145018

Updated

2 years ago
Depends on: 1207157
Added the site compatibility doc: https://www.fxsitecompat.com/en-US/docs/2015/css-float-bugs-have-been-fixed/
Keywords: dev-doc-needed, site-compat

Updated

2 years ago
Depends on: 1196255
Added a brief note here: https://developer.mozilla.org/en-US/Firefox/Releases/42#CSS
Keywords: dev-doc-needed → dev-doc-complete
Blocks: 1138328

Updated

a year ago
Depends on: 1260031
You need to log in before you can comment on or make changes to this bug.