132021 - [FLOAT]Elements containing an image get too wide after floated image

Status: RESOLVED WONTFIX

(Core :: Layout, defect)

Description

[Eric A. Meyer (dead account)]

Inside a table cell, a floated image will cause a subsequent element that
contains only an image to become roughly as wide as the image in the element
plus the width of the floated image.  It's tough to describe, which is why I'm
about to attach a testcase.  This only happens to the first such image to follow
the float; and following elements of a similar nature will be the correct width.

Furthermore, the element will grow only if the contained image is given a length
value for a width.  If the image is given a percentage width, the problem
doesn't happen.  And finally, this doesn't happen at all in non-table
environments.  See the testcase for examples of each.

Comment 1

[Eric A. Meyer (dead account)]

Attachment: One problem case and three ways to avoid it

In addition to the points above, it's also possible to avoid the problem by
using 'clear'.	(Say it with me: see testcase!)

Comment 2

[Amarendra Hanumanula]

 Confirmed and adding a testcase keyword.

Comment 3

[Bernd]

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

Comment 4

[Bernd]

this is a maxElementsize problem
      rowG 00B70F54 r=0 a=UC,UC c=UC,UC cnt=907 
        row 00B74B90 r=0 a=UC,UC c=UC,UC cnt=908 
         cell 00B74D04 r=0 a=UC,UC c=UC,UC cnt=909 
          block 00B74D64 r=0 a=UC,UC c=UC,UC cnt=910 
           text 00B77670 r=0 a=UC,UC c=UC,UC cnt=911 
           text 00B77670 d=0,0 me=0 
           place 00B77AA4 r=0 a=UC,UC c=UC,UC cnt=912 
           place 00B77AA4 d=0,0 me=0 
           img 00B77994 r=0 a=UC,UC c=1500,1500 cnt=913 
           img 00B77994 d=1500,1500 me=1500         // first image is 100px wide
           text 00B77AD4 r=0 a=UC,1500 c=UC,UC cnt=914 
           text 00B77AD4 d=0,0 me=0 
           block 00B77BF8 r=0 a=UC,UC c=UC,UC cnt=915 
            text 00B77C7C r=0 a=UC,UC c=UC,UC cnt=916 
            text 00B77C7C d=47550,285 me=1140 
           block 00B77BF8 d=48990,300 me=2640 
           text 00B77CEC r=0 a=UC,UC c=UC,UC cnt=917 
           text 00B77CEC d=0,0 me=0 
           block 00B77E3C r=0 a=UC,UC c=UC,UC cnt=918 
            img 00B77F9C r=0 a=UC,UC c=4500,75 cnt=919 
            img 00B77F9C d=4500,75 me=4500    //second image is 300px wide
           block 00B77E3C d=6000,75 me=6000   //maxelementsize is the sum of
100px and 300px 
           text 00B78108 r=0 a=UC,UC c=UC,UC cnt=920 
           text 00B78108 d=0,0 me=0 
          block 00B74D64 d=48990,1500 me=6000 
         cell 00B74D04 d=49020,1530 me=6030 
        row 00B74B90 d=UC,1530 
       rowG 00B70F54 d=UC,1530 

Comment 5

[Bernd]

This is not a table bug but a float line layout bug. The line should report a
maxElementsize of 4500. And the "good" thing is that there is now place where we
bury float bugs. Reassigning.

Comment 6

[Boris Zbarsky [:bzbarsky]]

floaters -- ccing waterson.  :)

Comment 7

[Chris Waterson]

This behavior is intentional (see bug 97383). :-)

When we compute the max element size (MES) for an individual line (in
nsBlockFrame::ComputeLineMaxElementSize), we include the width of the widest
floater on the line in that computation. During the unconstrained reflow, we end
up with layout that looks like:

  +-----+
  |float| blah blah blah blah blah ....
  |     | ---- (wide image here) ----
  +-----+

Giving us an MES that includes both the float and the wide image. After doing
second pass reflow (and _only_ after doing a second pass), do we determine that
the wide image wouldn't be affected by the floater:

  +-----+
  |float| blah blah blah blah
  |     | blah blah blah blah
  +-----+ blah blah blah blah
  blah blah blah...
  --- wide image here ---

So, yeah, we over-estimate the MES in this case. dbaron and I agreed that this
is better than _under-estimating_ the MES, which allows for wide text or images
to run outside the table cell. (Look at how IE and Nav4 handle some of the test
cases in bug 97383.)

There is no way to handle this situation correctly short of allowing layout to
compute a fix point; i.e., keep reflowing until nothing changes position anymore.

cc'ing other layout folks so they're aware of this.

Comment 8

[Chris Waterson]

...and marking WONTFIX.

Comment 9

[Bruce Brackbill]

You really want Mozilla to widen the table cell past its contraint
when there is no image in the cell that is wider than the cell?
This shows the problem:
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=81272

Both IE and NS do not widen the cell/column.  In otherwords
it looks correct in IE and NS4 and not Mozilla.  I imagine that
leaving this wontfix will break quite a few sites.