193666 - {inc}Rowspan is not handled properly in conjunction with images

Status: RESOLVED WORKSFORME

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

Description

[Janick Bernet]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130

The code in additional information works good in all browsers i tested (ie 5,
opera 6 & 7), only mozilla displays the second graphic on a new row. The
reproduce it replace the img tags with ones which really point to some images,
because if the image is not found, the alt-text is shown correctly.

Reproducible: Always

Steps to Reproduce:
see details



<table border=0 cellpadding=0 cellspacing=0 style="display:inline;">
<tr>
 <td rowspan=2 valign=middle><input class=Text type=text name="Test" size=10
maxLength=10></td>

<td width=12 valign=middle align=right><a href="javascript:
increase(document.TestForm.Test);"><img src="/Images/Increase.gif" width=8
height=8 valign=middle alt="+"></a></td>
</tr>
<tr><td width=12 valign=middle align=right><a href="javascript:
decrease(document.TestForm.Test);"><img src="/Images/Decrease.gif" width=8
height=8 valign=middle alt="-"></a></td></tr>
</table>

Comment 1

[Bernd]

there are two issues with the code first: display:inline,  it should probably be
display:inline-table
those statements are not identical and using the first one creates a anonymous
table around the tr. Mozilla does not support display:inline-table. Does the
code work when you remove the display:inline ?

Comment 2

[Janick Bernet]

If i remove the inline-directive then it displays fine. BUT I tink this is a bug
anaway, becaus if I use inline, but replace the Images with normal text it
dsiplays correctly, too. Also I think the display:inline-properity should only
affect the table itself and not the cells.

Comment 3

[Janick Bernet]

Attachment: Three examples

Three cases:
First is without inline
Second is with inline, but without images
Third is inline, and images --> bug!?

Comment 4

[Boris Zbarsky [:bzbarsky]]

That attachment does not seem to be a testcase for this bug....

Comment 5

[Janick Bernet]

Attachment: Reduced Testcase, well formatted

Made first attachement more "test-case-like" by reducing to only needed and
cleaning up html-source.

Comment 6

[Boris Zbarsky [:bzbarsky]]

In the third testcase, the two cells in the first row are different heights (!).
 That's the problem....

Comment 7

[Janick Bernet]

Huh? There are no heights defined as far I can see. And surely there is no 
difference in definition, except from the mentioned ones, in the three 
testcases, because they are auto-generated.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Yeah, that's the bug, see.  In the third testcase, the first cell in the first
row is the height of the <input> while the second is the height of the <img>. 
The whole row is the height of the <img> (shorter than one of its cells!).

I bet that would happen in the second testcase too, if you decreased the
font-size and line-height of the text you replaced the image with....

Comment 9

[Janick Bernet]

I played with different font- and image-sizes, but the result is always the same: normal text looks correct, images are messed up! I think that the inline properity affects the images of some sort, but not the text (because text is no extra tag!?)

Comment 10

[Janick Bernet]

Attachment: Testcase validated

Validated using utf-8, HTML 4.1 Transitional

Comment 11

[Janick Bernet]

Attachment: Testcase validated

Validated using utf-8, HTML 4.01 Transitional

Comment 12

[Janick Bernet]

Downloaded Version 1.3. Bug still there.

Comment 13

[Janick Bernet]

Here comes the brain-teaser: If you change the font size after loading the page,
the third row is also rendered correctly. But if you reload the page, with the
changed font size, it get's messed up again. That behaviour is independant of
the actual font size.

Comment 14

[Janick Bernet]

Is anyone working on this? I can still reproduce it in Deer Park Alpha 2. 
Please check if you can reproduce this, otherwise I will try to do a better
testcase which shows the error on any machine. I will also try to make a better
testcase.

Comment 15

[Boris Zbarsky [:bzbarsky]]

If someone were working on this, the bug would be assigned to that person...

Comment 16

[Janick Bernet]

Attachment: Simplified Testcase

Looks like bug also appears for text-only, too.

Comment 17

[Janick Bernet]

(In reply to comment #15)
> If someone were working on this, the bug would be assigned to that person...
That was more of a rethorical question :)

Comment 18

[Steve England [:stevee]]

Well, the "simplified testcase" layout has changed between:
- Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/2006120606 Minefield/3.0a (pre-reflow branch)
- Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/2006120804 Minefield/3.0a1 (post-reflow branch)

But i don't know if the new behaviour is the expected behaviour.

Comment 19

[Boris Zbarsky [:bzbarsky]]

Janick, the testcases look ok to me in a trunk build... are you still seeing this bug on trunk?

Comment 20

[Janick Bernet]

The current trunk build is crashing on me. I will try to test again in a few days.

Comment 21

[Bernd]

Janick can you please test again with a recent trunk build http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/latest-trunk/

Thanks, 

(it looks like wfm, but I do not really grasp what the issue is with the testcase)

Comment 22

[Bernd]

please reopen if you still see this bug and explain what is wrong