Open Bug 425524 Opened 16 years ago Updated 2 years ago

[quirk] replaced elements shouldn't wrap past tables that are floated with the align attribute

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

People

(Reporter: bugzilla-graveyard, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

(Keywords: regression)

Attachments

(5 files, 1 obsolete file)

Testcase
659 bytes, text/html
Details
test case minimised from URL
1.23 KB, text/html
Details
New Testcase
572 bytes, text/html
Details
simple testcase
217 bytes, text/html
Details
simplified testcase
583 bytes, text/html; charset=iso-8859-1
Details 
This is sort of similar to the good old WSJ TE bug (bug 330575). Camino lays out pages such as

http://www.local6.com/news/15712651/detail.html

and

http://www.local10.com/news/15714414/detail.html

with a large block of white space to the right of the sidebar and the main content below the sidebar.

Firefox does not. However, I have yet to successfully spoof as Firefox using either Camino trunk or branch.

Filing as UNCO in Camino for now so I don't forget about it, but this may very well be TE.
With both URI, I get exactly the same rendering with Camino trunk and Minefield latest. iirc, there is a core bug somewhere with a very similar layout, I'll have to check
This is a trunk layout bug (or a TE bug with the trunk).  Branch Caminos lay out the same (correct) way as branch Firefoxen, and trunk Caminos lay out the same (broken) way as trunk Firefoxen and Minefields.

--> Core:General for further triage.
Component: Page Layout → General
Product: Camino → Core
QA Contact: page.layout → general
Summary: CMS used on several news sites lays out pages oddly in Camino → CMS used on several news sites lays out pages oddly on trunk
Version: unspecified → Trunk
Attached file Testcase — 
basic test case,

Firefox: Text appears below picture
Opera: Text appears right of picture
So, this changed as follows:
2008012804 Minefield/3.0b3pre works
2008012904 Minefield/3.0b3pre fails

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2008-01-28+04%3A00%3A00&maxdate=2008-01-29+04%3A00%3A00&cvsroot=%2Fcvsroot

--> bug 134706

The problems is that computed width of the 'right column' (a table) is wider than the allocated space (1000px), and hence drops below the left column (a floated table).

Additionally, the content of the 2 tables makes them wider than the specified width(s).
e.g. the left table has a specified width of 133px; but contains an image 134 px wide.

The page is in standards mode.
Trying to come up with a simplified test case.
Blocks: 134706
First bugzilla post
Maybe this will help.  The CMS on the above news sites is made by 'Internet Broadcasting Systems'.  Their wikipedia page http://en.wikipedia.org/wiki/Internet_Broadcasting list alot of the sites which they have created. The sites listed under 'Post-Newsweek Stations' all seem to have the issue.  Th issue seems to appear mainly on the 'Local News' section of the affected sites.  Maybe comparing the CSS/Div/Table structure on this section of the sites to the other sections where the problem is not presenting itself will help.
Also, this bug is confirmed on Windows XP (no just for MACS) Gecko/2008042913 Minefield/3.0pre


I believe this is still serious enough regression, possible block on 1.9?
Flags: blocking1.9?
I'm going to go ahead and confirm this since it is a regression and we have a definite regression window and cause.

Philippe, any more luck coming up with a simplified testcase, or is the one in comment 3 good enough for our purposes?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
I don't think the test case in comment 3 is a bug. Safari does the same as Gecko 1.9, and it is pretty much the same as the issues in bug 393528 (auto-width floated containers).

And no, I haven't come up with a good test case yet.

marking 'all' per comment 6
OS: Mac OS X → All
Hardware: Macintosh → All
does the testcase and website act in the same way in safari? 
(In reply to comment #10)

The test case in comment 3: yes.
The website linked in the url field: no.
(although in some very partial reduction I made, both Opera and Safari acted the same as gecko)

dbaron/roc: can we get an opinion on whether or not this blocks?
Component: General → Layout
QA Contact: general → layout
In both Opera 9.5b and latest WebKit build + Safari the 'right column' (a table, light green + grey blocks) slightly overflows the orange box (wrapper).
Attached file New Testcase — 
Firefox 2, IE 6/7, Opera 9.5, and Safari show this test correctly. Firefox 3.0 will show the red bar at the bottom.
(In reply to comment #12)
> dbaron/roc: can we get an opinion on whether or not this blocks?

Ping. Need a decision here today, otherwise it's not gonna block.

It does look like attachment #319361 [details] is a real bug. The outer table cell's min-width should include both the width of the float and the width of the second inner table, as far as I can tell, since they have the same block parent.
Attached file simple testcase — 
Without divs
(In reply to comment #16)
> It does look like attachment #319361 [details] is a real bug. The outer table cell's
> min-width should include both the width of the float and the width of the
> second inner table, as far as I can tell, since they have the same block
> parent.

Well, I think the table probably counts as a block in our implementation...
Attached file testcase without tables (obsolete) — 
Here's a testcase without tables.

In FF3, when we compute the min-width of the outer float lColumn's width is not added to tColumn's width because tColumn is not inline content.

Safari 3.1 apparently computes the same min-width, but places tColumn next to lColumn anyway, making it overflow the outer float. Not sure if that's intentional but I'd say that's actually worse than what we do.
I'd also note that WinIE7 and Opera (9.27 and 9.50b2) do the same thing that we currently do on attachment 319433 [details].  So I'm not sure attachment 319433 [details] is an accurate simplification of the problem (given that WinIE differs from trunk on the other testcases).
imo seems like a serious regression, will this be blocking 3.0? 
This probably shouldn't block. Webkit does something obviously wrong and Opera and IE use different heuristics for min-width computation which we definitely are not going to match.
This problem appears to happen on foxnews.com as well, when reading articles there.
Not blocking as per comment 22, potentially an INVALID, but I'll let dbaron decide.
Flags: blocking1.9? → blocking1.9-
Perhaps rather than INVALID, this should be transferred to a web developer outreach issue, to try to get this issue resolved on the sites themselves?
(In reply to comment #23)
> This problem appears to happen on foxnews.com as well, when reading articles
> there.

What makes you think it's the same problem?  Did you reduce it to a similar testcase as one of the ones above?  If not, it should probably be a separate bug.
OK, granted, no, I didn't do that.  It just looks the same, with a sidebar appearing above the content.  Mea culpa.
(In reply to comment #25)
> Perhaps rather than INVALID, this should be transferred to a web developer
> outreach issue, to try to get this issue resolved on the sites themselves?

If someone is willing to take this on as a TE issue that's fine, but please don't just kick it to the TE component in the hope that it will magically get evangelised. TE is short-staffed and under-funded, and by "short" and "under" I mean "not", and things like this tend to go over there to die unless someone is willing to make this his pet bug.
So of the two testcases that are simple enough for me to understand in my head, I think we should perhaps fix attachment 319411 [details], but our layout of attachment 319361 [details] definitely looks correct (at least assuming it has the missing <tr> added back in, which I think we'll do even though it's not there) given the widths on the table and the cell.

(Attachment 319361 [details] is testing minimum intrinsic width calculation; attachment 319411 [details] is testing preferred intrinsic width calculation.)

It's not clear to me which of those testcases is an accurate simplification of the problem on the page.
Can we please not fill up the bug with discussion of whether it should be moved to TE until we actually know what's going on?  It's hard enough to understand what's going on here.
I also don't want to change the way we display attachment 313074 [details]; that testcase is much different since it has two floats whereas all the others have a non-floating table next to a float.
So I've looked at this page a bit more.  The problem is that the right cell of the table (id=tmp10td3, which contains from "Power Search" down to "Consumer Info / Sponsored Content Provided by ARA") that's getting pushed down below the float is ending up wider than it's supposed to be.  There's nothing wrong with the code that decides whether things should get pushed below floats.  The problem is that the right cell (id=tmp10td3) ends up 201px wide instead of 193px wide, which makes the table containing (id=tmp10) it 868px wide instead of 860px wide, which means that the 868px-wide table (id=tmp10) doesn't fit next to a 133px-wide float inside its 1000px-wide parent (id=vtmp10).

I still haven't figured out why the cell with id=tmp10td3 is too wide.  (Sometimes it's even wider than 201px.)
Er, I guess it has 201px-wide images in it, which is why it ends up 201px wide.

And in the other cells there's a div with width: 640px, padding-left: 10px, and padding-right: 10px (class=Story) inside a td (id=c1r1tbltd1) with border-right-width:7px, so the other cell really needs to be 667px wide.

667 + 201 == 868, which is more than the specified width of 860.  So it really just seems like tho author did math wrong.
Er, ok, the testcases about the big structure of the page are correct -- the issue seems to be that IE treats wrapping around floating tables differently from wrapping around other floats; I suppose it's just a quirk.  That seems pretty messy for us to emulate.
Er, I take that back.  It's treating style="float:left" differently from align="left" on tables.
Attached file simplified testcase — 
I simplified the page to this.  If you change align="left" on the table to style="float:left", IE will match Mozilla.

That's a pretty nasty quirk that would require a good bit of code to emulate, and I'd rather not -- certainly not based on just this one site.
Should the behaviour in attachment 319411 [details] be a separate bug than? IMO the regression against 1.8x is serious enough.
Note:
Opera9.2/9.5b shows the "nasty quirk" here, IE7 does not (align=left vs float:left).
Flags: blocking1.9.1?
Summary: CMS used on several news sites lays out pages oddly on trunk → [quirk] replaced elements shouldn't wrap past tables that are floated with the align attribute
Flags: wanted1.9.1-
Flags: blocking1.9.1?
Flags: blocking1.9.1-
Now browsers agree on the rendering for most of these tests, with one exception:

dbaron's "simple testcase" is still broken in Gecko and working in the others:
https://bug425524.bmoattachments.org/attachment.cgi?id=319411
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: