Build ID: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a8pre) Gecko/2007091904 Minefield/3.0a8pre
Summary: netscape.aol.com "Search" textfield renders below its constrained area.
(Summary sucks, sorry! Tweak as we go...)
Steps to Reproduce:
1. Load http://netscape.aol.com (or http://aol.com; they're identical besides their branding)
2. Look at the "Search" textfield in relation to the "Sign In" area.
See screenshot; the "Search" textfield should be flush inline with the Netscape/AOL logo to its left
The "Search" textfield overflows below, and is overlayed by the "Sign In" area
Created attachment 281578 [details]
Screenshot of it working in 184.108.40.206
Created attachment 281579 [details]
Screenshot of trunk layout regression
Might be related to / a duplicate of bug 396811 at its core.
Not a dupe of bug 396811 -- it has to do with nested floats. Posting a reduced testcase shortly.
Created attachment 281748 [details]
image for use in testcase
Created attachment 281749 [details]
Reduced testcase #1
For some reason, in Trunk, the last two a's in this testcase wrap to the second line, no matter how many a's there are.
From experimenting with larger images, it looks like the second line of a's is approximately as wide as the image in most cases.
Created attachment 281750 [details]
Reduced Testcase #2
Here's a second testcase with a wider image. Note that more a's are wrapped with the wider image. Again, it looks like the second line is approximately as wide as the image. (As in the previous testcase, you can add more a's, but the same number will be wrapped.)
Created attachment 281759 [details]
This page with a series of testcases demonstrates how we wrap the text as it gets longer and longer.
Possibly related to bug 395687.
(In reply to comment #9)
> Possibly related to bug 395687.
Actually, probably not -- bug 395687 is regression from bug 384876, but this bug here is not.
The problem seems to be this (looking at Reduced Testcase #1):
The first time we call GetPrefWidth() on the div, we act as if there will be a break between the image and the text. This makes us assign the div a pref width of MAX(textWidth, imageWidth) = textWidth
However, when we actually lay it out, the image and text end up being on the same line. Still, we told the div to be just as wide as the text, and so the image displaces some text, forcing it to wrap onto a second line.
According to the Firefox 2 rendering, the image and text *should* end up on the same line, so the reflowing is correct, but the initial div prefWidth assignment is incorrect.
Safari/Webkit actually has this same bug -- it behaves pretty similar to Trunk on the tescases. And it only handles netscape.aol.com correctly because AOL sends it *different HTML*, using user-agent sniffing. If you give Safari the Mozilla-specific version of the page, Safari looks just as bad as Trunk.
(You can get the Mozilla version of the page by viewing it with any Mozilla browser and saving it as "HTML Complete". If you load that in Safari, you'll see the exact same problem that we're getting in Trunk. You get the same results if you spoof Safari's user-agent.)
This bug's related to bug 383373, which is marked WONTFIX
This regressed between 2006-12-07-04 (Works) and 2006-12-08-04, which fails.
http://tinyurl.com/3brd74 (reflow branch?)
Daniel, you wrote some tests here back in '07 but Chrome doesn't render any of them per expectations. On the other hand, Chrome and Firefox anno '15 agree nearly perfectly on all tests. Are the tests and this bug invalid by some change in float spec or implementation since 2007?
(In reply to Hallvord R. M. Steen [:hallvors] from comment #15)
> Daniel, you wrote some tests here back in '07 but Chrome doesn't render any
> of them per expectations.
Right, that was true for WebKit-derived browsers at the time, too; see beginning of comment 12.
> On the other hand, Chrome and Firefox anno '15
> agree nearly perfectly on all tests.
(As noted above, this was true in 2007 too, for Safari, pre-Chrome)
> Are the tests and this bug invalid by
> some change in float spec or implementation since 2007?
I don't think anything's changed, but it's possible the spec calls for the rendering that everyone seems to agree on.
The fundamental weirdness with that rendering is that, in e.g. testcase 1, we're wrapping text to a new line when we really don't have to, space-wise. (since width is unconstrained and we're just doing intrinsic sizing via floats). That seems a bit broken, and it caused problems with one particular website back in 2007. It might be per spec though.
(The "reference" browser for the attached testcases, back when this bug was filed, was Firefox 2.0, per comment 1.)
Maybe dbaron understands something me and Daniel don't? :)
So this bug isn't AFAIK a problem - and the way browsers agree makes it unlikely to become a problem - but it's odd..
It's currently unspecified behavior since intrinsic width calculation is not defined. It's possible it will be defined to match our behavior, though. We used to behave differently, and IE has behaved differently for a long time.
Probably the closest thing to a spec is:
*** Bug 440042 has been marked as a duplicate of this bug. ***