396821 - pref width doesn't account for float being next to contents of following block

Status: NEW

(Core :: Layout, defect, P5)

Description

[Stephen Donner [:stephend] Not actively reading bugmail]

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.

Expected Results:

See screenshot; the "Search" textfield should be flush inline with the Netscape/AOL logo to its left

Actual Results:

The "Search" textfield overflows below, and is overlayed by the "Sign In" area

Comment 1

[Stephen Donner [:stephend] Not actively reading bugmail]

Attachment: Screenshot of it working in 2.0.0.7

Comment 2

[Stephen Donner [:stephend] Not actively reading bugmail]

Attachment: Screenshot of trunk layout regression

Comment 3

[Stephen Donner [:stephend] Not actively reading bugmail]

Might be related to / a duplicate of bug 396811 at its core.

Comment 4

[Daniel Holbert [:dholbert]]

Not a dupe of bug 396811 -- it has to do with nested floats.  Posting a reduced testcase shortly.

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: image for use in testcase

Comment 6

[Daniel Holbert [:dholbert]]

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

Comment 7

[Daniel Holbert [:dholbert]]

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

Comment 8

[Daniel Holbert [:dholbert]]

Attachment: Megatest

This page with a series of testcases demonstrates how we wrap the text as it gets longer and longer.

Comment 9

[Daniel Holbert [:dholbert]]

Possibly related to bug 395687.

Comment 10

[Daniel Holbert [:dholbert]]

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

Comment 11

[Daniel Holbert [:dholbert]]

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.

Comment 12

[Daniel Holbert [:dholbert]]

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

Comment 13

[Daniel Holbert [:dholbert]]

This bug's related to bug 383373, which is marked WONTFIX

Comment 14

[Stephen Donner [:stephend] Not actively reading bugmail]

This regressed between 2006-12-07-04 (Works) and 2006-12-08-04, which fails.

http://tinyurl.com/3brd74 (reflow branch?)

Comment 15

[Hallvord R. M. Steen [:hallvors]]

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?

Comment 16

[Daniel Holbert [:dholbert]]

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

Comment 17

[Daniel Holbert [:dholbert]]

(The "reference" browser for the attached testcases, back when this bug was filed, was Firefox 2.0, per comment 1.)

Comment 18

[Hallvord R. M. Steen [:hallvors]]

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

Comment 19

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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:
https://lists.w3.org/Archives/Public/www-style/2014Nov/0085.html

Comment 21

[Mats Palmgren (inactive)]

Attachment: Megatest

Updated "Megatest" with "font:16px/1 monospace" to make it easier
to compare the rendering with Chrome.

Comment 22

[Mats Palmgren (inactive)]

The "Megatest" renders exactly the same in Chrome and Firefox.
The web-compat risk of changing our intrinsic size calculations
at this point is INSANELY high and we certainly can't do it without
Chrome also changing their layout in exactly the same way.
So, I tend to think this is a WONTFIX bug at this point.