Closed
Bug 478834
Opened 16 years ago
Closed 9 years ago
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
Categories
(Core :: Layout: Floats, defect)
Core
Layout: Floats
Tracking
()
RESOLVED
FIXED
mozilla42
People
(Reporter: punungwe, Assigned: dbaron)
References
()
Details
(Keywords: dev-doc-complete, site-compat, Whiteboard: [compat])
Attachments
(12 files)
(deleted),
image/png
|
Details | |
(deleted),
image/png
|
Details | |
(deleted),
image/jpeg
|
Details | |
(deleted),
image/png
|
Details | |
(deleted),
image/png
|
Details | |
(deleted),
image/png
|
Details | |
(deleted),
image/png
|
Details | |
(deleted),
text/html
|
Details | |
(deleted),
text/html
|
Details | |
(deleted),
text/html
|
Details | |
(deleted),
text/html
|
Details | |
(deleted),
patch
|
roc
:
review+
|
Details | Diff | Splinter Review |
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.
Comment 1•16 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
Version: unspecified → 3.0 Branch
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.
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
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.
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.
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.
Whiteboard: [CLOSEME 2010-11-01]
Reporter | ||
Comment 12•14 years ago
|
||
The problem as seen on my computer still hapens.
Updated•14 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•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)"
Reporter | ||
Comment 14•14 years ago
|
||
The bug was also observed with Minefield 4.0b7pre
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)
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
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?
Component: Layout: Tables → Layout
QA Contact: layout.tables → layout
Comment 17•14 years ago
|
||
Chromium matches the Opera & IE rendering, FWIW (shown in attachment 400326 [details])
Updated•14 years ago
|
Keywords: qawanted,
testcase-wanted
Comment 18•13 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.
Updated•13 years ago
|
Keywords: testcase-wanted
Comment 19•13 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.
Keywords: qawanted
Comment 20•13 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).
Comment 21•13 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. :)
Depends on: 653355
Whiteboard: DUPEME
Comment 23•13 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.
Comment 24•13 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....
Updated•13 years ago
|
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
Comment 26•13 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.
Assignee | ||
Comment 27•13 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
Comment 28•13 years ago
|
||
Comment 32•12 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.
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.
Comment 35•10 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/
Assignee | ||
Comment 37•10 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•10 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.)
Comment 39•10 years ago
|
||
[Clearing stale "DUPEME" added in comment 21; the bug suggested as a dupe-target around there was later duped to this bug.]
Whiteboard: DUPEME
Comment hidden (obsolete) |
Comment 43•10 years ago
|
||
(meant to say: Expanding summary, per bug 1073574 comment 8)
Comment 44•10 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)
Comment 45•10 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.)
Component: Layout → Layout: Floats
Updated•9 years ago
|
Updated•9 years ago
|
Priority: P3 → --
Assignee | ||
Updated•9 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•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.)
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.
Attachment #8639611 -
Flags: review?(roc)
Assignee | ||
Comment 50•9 years ago
|
||
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.
Attachment #8639611 -
Flags: review?(roc) → review+
Assignee | ||
Updated•9 years ago
|
Flags: needinfo?(bugs)
Comment 52•9 years ago
|
||
Comment 53•9 years ago
|
||
Status: NEW → RESOLVED
Closed: 9 years ago
status-firefox42:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla42
Comment 67•9 years ago
|
||
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
Comment 68•9 years ago
|
||
Added a brief note here: https://developer.mozilla.org/en-US/Firefox/Releases/42#CSS
Keywords: dev-doc-needed → dev-doc-complete
You need to log in
before you can comment on or make changes to this bug.
Description
•