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.

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

Confirmed and adding a testcase keyword.

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

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

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.

floaters -- ccing 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.

...and marking WONTFIX.

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.