Floated element changes container width before float occurs

RESOLVED WORKSFORME

Status

()

RESOLVED WORKSFORME
11 years ago
10 years ago

People

(Reporter: mr_bliss, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0

This is a layout bug relating to CSS but this seems like an OK place to post it. Hopefully I'm not too far off.

This is a change in behavior from FF2 and means FF3 now behaves differently than the latest IE, Safari & FF2 on Windows. Not always a bad thing but in this case it seems to be the incorrect behavior. See linked images or url for example.

Reproducible: Always

Steps to Reproduce:
1. Open the example url or the prerendered FF3 XP image: http://www.lewinesque.com/images/firefox/bugs/FF3.png
2. Review the spacing between spans for FF3
3. Open the prerendered FF2 XP image: http://www.lewinesque.com/images/firefox/bugs/FF2.png
4. Review the spacing between spans for FF2
Actual Results:  
The span for the B series of elements is larger than its sibling spans.

Expected Results:  
I would have expected the width of all span elements to be the same. The width of the span containing the B series elements appears be the sum of its child elements widths rather than its largest child element. It seems likely that the width of the span is calculated before the float is applied.
(Reporter)

Comment 1

11 years ago
Created attachment 327204 [details]
Previous layout rendering in FF2
(Reporter)

Comment 2

11 years ago
Created attachment 327205 [details]
Current layout with FF3
Component: General → Layout
Product: Firefox → Core
QA Contact: general → layout

Comment 3

11 years ago
That test case suffers from bug 50630: the floated 'span em' (second row in the screenshots) should be positioned before the respective input fields, as Safari/Opera do.
That is fixed on trunk-mozilla-central 1.9.1pre builds; the test case displays the same as Safari/Opera.

On Gecko 1.9.0 - Fx 3, it looks like the browser reserve space to position the floated block on the same line, but can't due to the bug linked above.

Comment 4

10 years ago
(In reply to comment #3)
> On Gecko 1.9.0 - Fx 3, it looks like the browser reserve space to position the
> floated block on the same line, but can't due to the bug linked above.

Exactly. This is fixed on Shiretoko/trunk and FWIW in IE8 beta's as well.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.