100594 - {inc}text overwrites image within table cell

Status: RESOLVED WORKSFORME

(Core :: Layout: Floats, defect)

Description

[Sean Foley]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20010913
BuildID:    2001091303

On the right hand side of the page there are photos of columnists with their
names.  The first one, Allan Fotheringham, will at first have his photo being
overwritten with his name, when you first access one of the editorials -
although for some reason the rendering is always correct on the summary page
http://globeandmail.com/comment

Interestingly, when you access an editorial, if you hover the mouse over any one
of the links in the same table, then the rendering corrects itself, with his
name moving below the image!  You can then reproduce the error by going to a
different editorial.  



Reproducible: Sometimes
Steps to Reproduce:
1. go to http://globeandmail.com/comment
2. Click on an editorial link under "additional comment stories"
3. observe the image of Allan Fotheringham on the right side

Actual Results:  The name of Allan Fotheringham appears on top of his image.

Expected Results:  Mozilla should do immediately what is actually will do if you
hover the mouse over any link in the same table: it will move his name below his
image.

It seems to be connected to the fact that his name is long and will not fit to
the right of the image

Comment 1

[Marc Attinasi]

I see this in Netscape 6.1 too. I have a reduced testcase that wil help a bit,
just hover over the text-link and it will reflow and go wrong. However, in the
recent 0.9.4 branch build, the testcase is not always able to reproduce the
problem (the page is, however).

Over to tables to have a look.

Comment 2

[Marc Attinasi]

Attachment: reduced testcase: hover over link and text reflows over image

Comment 3

[Marc Attinasi]

Floated image is probably the problem, not the table. Chris, please feel free to
send it back if you rule out problems in tables.

Comment 4

[Jeremy Browne (no email)]

Attachment: Further reduced/cleaned up testcase

Comment 5

[karnaze (gone)]

In the 2nd attachment with an empty cache, the cell block containing the floater 
is given as much width as it wants but it is not enough. -->waterson

    Cell 01173D68 r=0 a=UC,UC c=2100,UC cnt=4
     Block 01173DC4 r=0 a=UC,UC c=UC,UC cnt=5
     Block 01173DC4 d=1680,540 me=1680
    Cell 01173D68 d=1710,570 me=1710  

    Cell 01173D68 r=2 a=2130,UC c=2100,UC cnt=8
     Block 01173DC4 r=2 a=2100,UC c=2100,UC cnt=9
     Block 01173DC4 d=2100,540
    Cell 01173D68 d=2130,570

    Cell 01173D68 r=1 a=2130,UC c=2100,UC cnt=14
     Block 01173DC4 r=1 a=2100,UC c=2100,UC cnt=15
     Block 01173DC4 d=2100,1230 me=1680 m=1680
    Cell 01173D68 d=2130,1260 me=1710 m=1710

Comment 6

[Chris Waterson]

I'm not able to reproduce this; however, it sounds an awful lot like bug 48138.
I'll mark as a dependant for now; we'll see if this goes away with dbaron's
block landing.

Comment 7

[karnaze (gone)]

I forgot to mention that I was using a fairly old build, so hopefully it is 
fixed.

Comment 8

[Pierre Saslawsky]

It is similar to bug 97776 which was closed as WFM.

Comment 9

[Jeremy Browne (no email)]

This bug, plus a separate one that was also visible in the testcase, is no
longer present in build id 2002011103.

Comment 10

[Jeremy Browne (no email)]

It's been at least ten months since this was fixed... This bug can now be closed
by someone with permission to do so.

Comment 11

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

OK, resolving as worksforme since we don't know what fixed it.