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

NEW
Unassigned

Status

()

Core
Layout
P5
trivial
10 years ago
2 years ago

People

(Reporter: stephend, Unassigned)

Tracking

(Blocks: 1 bug, {testcase, top100})

Trunk
x86
All
testcase, top100
Points:
---
Bug Flags:
blocking1.9 -
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [float pref width], URL)

Attachments

(5 attachments, 1 obsolete attachment)

(Reporter)

Description

10 years ago
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
(Reporter)

Comment 1

10 years ago
Created attachment 281578 [details]
Screenshot of it working in 2.0.0.7
(Reporter)

Comment 2

10 years ago
Created attachment 281579 [details]
Screenshot of trunk layout regression
(Reporter)

Comment 3

10 years ago
Might be related to / a duplicate of bug 396811 at its core.
(Reporter)

Updated

10 years ago
Flags: in-testsuite?
Not a dupe of bug 396811 -- it has to do with nested floats.  Posting a reduced testcase shortly.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows Vista → All
Summary: netscape.aol.com "Search" textfield renders below its constrained area. → Weird wrapping behavior for nested floats
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.
Attachment #281748 - Attachment is obsolete: true
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.)
(Reporter)

Updated

10 years ago
Keywords: testcase
Created attachment 281759 [details]
Megatest

This page with a series of testcases demonstrates how we wrap the text as it gets longer and longer.
Flags: blocking1.9?
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
Flags: blocking1.9? → blocking1.9-
(Reporter)

Comment 14

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

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

Updated

10 years ago
Keywords: top100
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?
Flags: needinfo?(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.
Flags: needinfo?(dholbert)
(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..
Severity: normal → trivial
Flags: needinfo?(dbaron)
Priority: -- → P5
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
Flags: needinfo?(dbaron)
Summary: Weird wrapping behavior for nested floats → pref width doesn't account for float being next to contents of following block
Whiteboard: [float pref width]
Duplicate of this bug: 440042
Blocks: 895989
You need to log in before you can comment on or make changes to this bug.