97383 - WRMB: Contents of 1st column does not render correctly

Status: VERIFIED FIXED

(Core :: Layout: Tables, defect, P2)

Description

[rubydoo123]

The attached testcase is a reduction of issues presented in bugscape bug 5895. 
When the 2nd column is inserted, the content of the 1st column drops down 
significantly.

Comment 1

[rubydoo123]

Attachment: reduced testcase

Comment 2

[Mats Palmgren (inactive)]

Attachment: Testcase #2

Comment 3

[Marek Z. Jeziorek]

adding topembed to WRMB bug

Comment 4

[karnaze (gone)]

waterson, in the 1st attachment, during an incremental reflow, the cell block in 
the outermost table is reporting too large (10845) a desired height, probably 
due to the floated image.

    Cell 01189F78 r=1 a=255,UC c=225,UC cnt=52
     Block 01189FD4 r=1 a=225,UC c=225,UC cnt=53
      Tbl 0118A204 r=1 a=225,UC c=0,0 cnt=54
       Tbl 0119F458 r=1 a=225,UC c=UC,UC cnt=55
        RowG 0119F530 r=1 a=135,UC c=135,UC cnt=56
         Row 0118A250 r=1 a=135,UC c=135,UC cnt=57
          Cell 0119F684 r=1 a=75,UC c=15,UC cnt=58
           Block 0118A29C r=1 a=45,UC c=45,UC cnt=59
           Block 0118A29C d=1875,3750 me=1875 m=1875
          Cell 0119F684 d=1905,3780 me=1905 m=1905
         Row 0118A250 d=135,3780
        RowG 0119F530 d=135,3780
Balanced min=1995 des=1995 pref=1995 cols=1905
        RowG 0119F530 r=2 a=1965,UC c=1965,UC cnt=60
         Row 0118A250 r=2 a=1965,UC c=1965,UC cnt=61
          Cell 0119F684 r=2 a=1905,UC c=1845,UC cnt=62
           Block 0118A29C r=2 a=1845,UC c=1845,UC cnt=63
           Block 0118A29C d=1875,3750
          Cell 0119F684 d=1935,3810
         Row 0118A250 d=1965,3810
        RowG 0119F530 d=1965,3810
       Tbl 0119F458 d=1995,3900 me=1995 m=1995
      Tbl 0118A204 d=1995,3900 me=1995 m=1995
     Block 01189FD4 d=1995,10845 me=1995 m=2100
    Cell 01189F78 d=2025,10875 me=2025 m=2130

Comment 5

[Chris Waterson]

From the Bugscape bug report:

2. Entire center portion of this page in NS is moved further down the page than
the graphics and words in IE.  Everything is present, just misplaced which
causes overlapping of graphics near bottom of site.
--> The images being dropped in the middle of the page (below the About Us 
button) is now bugzilla bug 97383.

Comment 6

[Chris Waterson]

What appears to be going on here is that the block frame in the left table cell
is reporting back a desired size of 2100 twips (== 125px for the image + 15px
for the floater), but a MES of 1875 twips (== 125px for the image). Since the
right table cell is requesting a width of 100%, we flow the left cell at the
minimum allowable width, 1875 twips, which forces the floater onto a separate line.

I'm not really sure what the right thing to do here is. Clearly the table code
can't know about the floater. Should we incorporate the float's width into the
MES in the block code?

Comment 7

[Chris Waterson]

Attachment: further minimized; get rid of image frame and shrink float to avoid extra reflows

Comment 8

[Chris Waterson]

Attachment: output with table debug and GECKO_BLOCK_DEBUG_FLAGS turned on

Comment 9

[Hixie (not reading bugmail)]

Why is what we are doing on that testcase wrong?

Comment 10

[Chris Waterson]

Actually, my test case (attachment 48211 [details]) that replaces the floated <img> with a
<div> lays out identically in both IE and Mozilla (with the float pushed down
below the in-flow image). The previous test case (attachment 47413 [details]), IE lays out
with the floated image on the same line as the inline image. Weird.

Comment 11

[Hixie (not reading bugmail)]

"IE sucks"? ;-)

A floated <div> and a floated <img> should act the same, per the specs.

Comment 12

[Chris Waterson]

Sigh. It looks like the ``de facto standard'' is that inline replaced elements
(well, at least <img>, <applet>, and <object>) that are left-floated appear to
count toward's the line's MEW in both IE and Nav 4.x. Worse, right-floated
elements appear to _not_ count against the MEW, but are instead flowed _on top
of_ the inline element.

Comment 13

[Chris Waterson]

Attachment: inline replaced element, left and right floated. compare vis a vis IE and Nav 4.x

Comment 14

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

Sigh.  The only reason we weren't fixing bug 95512 (see comments on bug 95511)
was exactly because it would break this behavior (bug 57828), except we only do
this for nowrap.  So when we fix this we should yank out the two
almost-cancelling-each-other bits of code that cause bug 95512 (see comments in
bug 95511).

I think what we really need is a way to account for floats in the
max-element-size (when to do it is the trick), to fix both this and allow us to
remove the hacks that are causing bug 95512.  (I think we should solve the "on
top of" problem better than 4.x/IE -- I doubt anyone depends on it, and it
should be considered a bug even if they do.)

Comment 15

[Chris Waterson]

Attachment: possible fix

Comment 16

[Chris Waterson]

Attachment: inline replaced element, left and right floated (redux)

Comment 17

[Chris Waterson]

It looks like kipp realized that he was going to create a compatibility problem.
The above patch (attachment 48634 [details] [diff] [review]) simply _includes_ the maximum element width
of any floaters on the line into the line's maximum element width when in quirks
mode.

This brings our compatibility with left-floats into sync with IE. We appear to
do a bit better than 4.x, which goofs up the width of the table cell in
attachment 48635 [details]. Our behavior with right-floats continues to be the same in
quirks and strict mode, somewhat to my surprise.

Comment 18

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

Hmmm.  The patch seems to make sense both for quirks and strict mode -- why do
we not want to do this in strict mode?  Also, after this is done, can you apply
attachment 46012 [details] [diff] [review] from bug 95511 to fix bug 95512 without breaking bug 57828?

Comment 19

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

To be a little clearer (I think), I think doing this for strict mode as well
would allow us to fix bug 95512 (using attachment 46012 [details] [diff] [review] from bug 95511) without
causing bug 57828 again.  What that patch does is remove two bits of code that
mostly cancel each other out -- and I think with this fix they wouldn't be
needed at all anymore.  I'm wondering to which CSS2 conformance tests Kipp was
referring.

Comment 20

[Chris Waterson]

Attachment: combined patch including attachment 46012 from bug 95511

Comment 21

[Chris Waterson]

Attachment 48932 [details] [diff] is as you request, dbaron. Re-reading bug 95512, I'm not sure
how to determine if we've ``fixed'' that bug or not. Certainly lxr.mozilla.org
renders just as poorly as before...

Comment 22

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

I'd be surprised if it doesn't fix the incremental reflow problem, since my
patch alone did.  (The layout should still be ugly, because it has manually
placed <br>s in it.)  What I was wondering was whether it would break bug 57828.

Comment 23

[Chris Waterson]

No, bug 57828 does not appear to regress (in fact, we now lay out the pages much
more like 4.x and IE, because we're guaranteed to place content on the same line
as the float), and lxr appears no better or worse.

Comment 24

[Marc Attinasi]

Comment on attachment 48932 [details] [diff] [review]
combined patch including attachment 46012 [details] [diff] [review] from bug 95511

sr=attinasi

Comment 25

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

I tested the patch and it fixes the incremental reflow problem in bug 95512 for me.

Comment 26

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

Comment on attachment 48932 [details] [diff] [review]
combined patch including attachment 46012 [details] [diff] [review] from bug 95511

r=dbaron if the block & table regression tests are happy

Comment 27

[Chris Waterson]

Fix checked in.

Comment 28

[Chris Waterson]

I should note that this will cause minor changes on the layout regression tests,
including the test cases for bug 57282 and bug 59280. In both these cases, we
lay out the content more compatibly with IE4 and Nav 4.x.

Comment 29

[Chris Waterson]

Re-opening for consideration on mozilla-0.9.4 branch.

Comment 30

[Chris Waterson]

Jumping around, trying to attract attention.

Comment 31

[Chris Waterson]

WRMB, nominating for branch.

Comment 32

[Jaime Rodriguez, Jr.]

PDT+. Pls check it in by 3 am.

Comment 33

[Chris Waterson]

Checked in on MOZILLA_0_9_4_BRANCH.

Comment 34

[Chris Waterson]

Fixing this bug caused bug 102100.

Comment 35

[Amarendra Hanumanula]

 NS6.2 is rendering the given test case right.. in IE the floated <div> and 
<image> tags do not render according to specifications...
Build ID : 2001-10-03-05-0.9.4
           2001-10-03-06-Trunk
Plat form: win2K and win98