Last Comment Bug 396821 - pref width doesn't account for float being next to contents of following block
: pref width doesn't account for float being next to contents of following block
Status: NEW
[float pref width]
: testcase, top100
Product: Core
Classification: Components
Component: Layout (show other bugs)
: Trunk
: x86 All
: P5 trivial with 2 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
http://netscape.aol.com
: 440042 (view as bug list)
Depends on:
Blocks: 895989
  Show dependency treegraph
 
Reported: 2007-09-19 17:52 PDT by Stephen Donner [:stephend]
Modified: 2015-07-28 09:29 PDT (History)
10 users (show)
roc: blocking1.9-
stephen.donner: in‑testsuite?
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Screenshot of it working in 2.0.0.7 (243.78 KB, image/jpeg)
2007-09-19 18:00 PDT, Stephen Donner [:stephend]
no flags Details
Screenshot of trunk layout regression (219.94 KB, image/jpeg)
2007-09-19 18:01 PDT, Stephen Donner [:stephend]
no flags Details
image for use in testcase (135 bytes, image/png)
2007-09-20 16:54 PDT, Daniel Holbert [:dholbert]
no flags Details
Reduced testcase #1 (518 bytes, text/html)
2007-09-20 16:59 PDT, Daniel Holbert [:dholbert]
no flags Details
Reduced Testcase #2 (695 bytes, text/html)
2007-09-20 17:05 PDT, Daniel Holbert [:dholbert]
no flags Details
Megatest (5.79 KB, text/html)
2007-09-20 17:23 PDT, Daniel Holbert [:dholbert]
no flags Details

Description Stephen Donner [:stephend] 2007-09-19 17:52:40 PDT
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] 2007-09-19 18:00:34 PDT
Created attachment 281578 [details]
Screenshot of it working in 2.0.0.7
Comment 2 Stephen Donner [:stephend] 2007-09-19 18:01:05 PDT
Created attachment 281579 [details]
Screenshot of trunk layout regression
Comment 3 Stephen Donner [:stephend] 2007-09-20 14:56:41 PDT
Might be related to / a duplicate of bug 396811 at its core.
Comment 4 Daniel Holbert [:dholbert] 2007-09-20 16:48:57 PDT
Not a dupe of bug 396811 -- it has to do with nested floats.  Posting a reduced testcase shortly.
Comment 5 Daniel Holbert [:dholbert] 2007-09-20 16:54:03 PDT
Created attachment 281748 [details]
image for use in testcase
Comment 6 Daniel Holbert [:dholbert] 2007-09-20 16:59:57 PDT
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.
Comment 7 Daniel Holbert [:dholbert] 2007-09-20 17:05:56 PDT
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.)
Comment 8 Daniel Holbert [:dholbert] 2007-09-20 17:23:21 PDT
Created attachment 281759 [details]
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] 2007-09-21 09:09:17 PDT
Possibly related to bug 395687.
Comment 10 Daniel Holbert [:dholbert] 2007-09-21 09:18:07 PDT
(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] 2007-09-21 12:54:16 PDT
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] 2007-09-21 15:53:39 PDT
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] 2007-09-21 16:08:33 PDT
This bug's related to bug 383373, which is marked WONTFIX
Comment 14 Stephen Donner [:stephend] 2007-10-10 00:27:31 PDT
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] 2015-07-28 04:09:49 PDT
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] 2015-07-28 07:44:03 PDT
(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] 2015-07-28 07:48:22 PDT
(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] 2015-07-28 07:58:29 PDT
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-7 (review requests must explain patch) 2015-07-28 09:27:14 PDT
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 20 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2015-07-28 09:27:53 PDT
*** Bug 440042 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.