38157 - Floater without a specified width should take up remaining available width

Status: VERIFIED FIXED

(Core :: Layout, defect, P1)

Description

[Simon Brooke]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.14-15mdksmp i686; en-US; m15)
BuildID:    2000041811

This is a w3c page, and needless to say it validates properly. It displays fine
in Netscape 4.6; however in Mozilla M15 the content is squashed into tall,
narrow strip to the left of the page, with the bulk of the page left blank.

Reproducible: Always
Steps to Reproduce:
1. Point your browser at http://www.w3.org/Jigsaw
2. Errr... that's it.
3.

I validated the page against the validator at http://validator.w3.org/, and got:

URI: http://www.w3.org/Jigsaw/
      Last modified: Thu Apr 27 09:06:46 2000
      Server: Apache/1.3.6 (Unix) PHP/3.0.15
      Content length: 16781
      Character encoding: iso-8859-1
      Document type: HTML 4.0 Transitional

Below are the results of attempting to parse this document with an SGML parser.

    No errors found!

Comment 1

[Blake Ross]

I see this on the page you gave as well as http://www.betanews.com (something 
similar) with 2000050308 win98

Comment 2

[Kevin McCluskey (gone)]

Reassigning to karnaze. Triaging Troy's bug list.
Looks like a table layout problem.

Comment 3

[Bernd Mielke]

The behaviour has changed while with a 2000032909 build I get a to small main 
section. It is now with a build from 20000512 to wide and goes after the left 
column. The page does not contain a single <table> tag so I doubt that this is 
karnaze's field.

Comment 4

[Bernd Mielke]

Attachment: testcase with div tags

Comment 5

[karnaze (gone)]

Buster, the test case has no tables.

Comment 6

[buster]

the positioned <DIV>'s do not have any width assigned to them.  so, they are 
getting their intrinsic width.  In the case of the second <DIV>, that's very 
large because of the long text run.  Since the second <DIV> does not fit in the 
space next to the first, it is pushed down to the next line as per CSS2 spec.

I think what we should be doing here, and what Nav and IE seem to do, is give 
the floater the remaining space in the absence of any other width information. 
I'll have to look into it further to see what the spec says about floated blocks 
that have no assigned width.  cc'd David in case he already knows the 
answer.

Comment 7

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

The CSS2 (and perhaps CSS1) specs say that floats with no specified with should
have (or tend towards, because of minimum width of inline content) width 0. 
However, I think some folks want to change this, as shown by Mozilla's current
implementation.  I guess it's really up to you (perhaps it's worth discussing
this with the WG?) how you want to deal with this.  CSS1/2 would have a wide
float move to the next line, but that doesn't seem to make too much sense here,
since the float's width is only being limited by available space...

Comment 8

[buster]

this is a part of the spec that has not been well defined.  Troy implemented it 
as best he could with the interpretation at that time, but it looks like we'll 
need to enhance the behavior here.

Comment 9

[Bernd Mielke]

By the way this bug duplicates bug 36587, which was closed as worksforme ????
and assigned to troy.

Comment 10

[buster]

*** Bug 36587 has been marked as a duplicate of this bug. ***

Comment 11

[buster]

moving nsbeta2 nomination from dup'd bug.  This seems to happen on a fair number 
of pages, we'll get lots of bug reports for beta2 unless we fix this.
Est. time to fix: 2 days.
Risk: low to moderate.

Comment 12

[buster]

I know the general form of the solution now, working out some remaining bugs.

Comment 13

[buster]

I think the remaining problem with my fix is really a GFX Scrollbar bug.  If I 
turn off GFX scrollbars, resizing works perfectly.  With GFX Scrollbars turned 
on, resizing doesn't work because the body is being told it has more available 
width than it should really have.  Could still be my fault, I'm checking...

also need to test multiple stacked floaters, all of which are without a 
specified width.

Comment 14

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

The GFX scrollbar bug is probably bug 35681.

Comment 15

[Phil Peterson]

[nsbeta2+]

Comment 16

[buster]

fix checked in

Comment 17

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

Restoring original information from weird bug changes (probably caused by 
Mozilla bugs).  This isn't the best time to use Mozilla on Bugzilla...

Comment 18

[buster]

Attachment: test case for the remaining problem

Comment 19

[ekrock's old account (dead)]

Steve, by "remaining problem" do you mean bug 42685? If so, one of us should 
make a notation in bug 42685 that a test case relevant to us is present in this 
bug.

If not, could you please REOPEN this or open a separate report if it's a new 
issue? Thanks!

Comment 20

[Chris Petersen]

Is this bug truely fixed ? I don't see the original probelm as reported.

Comment 21

[Chris Petersen]

With the June 30th build, the problem appears to be fixed.