Closed
Bug 193666
Opened 22 years ago
Closed 15 years ago
{inc}Rowspan is not handled properly in conjunction with images
Categories
(Core :: Layout: Tables, defect, P3)
Tracking
()
RESOLVED
WORKSFORME
Future
People
(Reporter: jabernet, Unassigned)
Details
(Keywords: testcase)
Attachments
(1 file, 4 obsolete files)
(deleted),
text/html
|
Details |
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>
Reporter | ||
Updated•22 years ago
|
Summary: Rowspan is not handled properly → Rowspan is not handled properly in conjunction with images
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 ?
Reporter | ||
Comment 2•22 years ago
|
||
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.
Reporter | ||
Comment 3•22 years ago
|
||
Three cases:
First is without inline
Second is with inline, but without images
Third is inline, and images --> bug!?
Comment 4•22 years ago
|
||
That attachment does not seem to be a testcase for this bug....
Reporter | ||
Comment 5•22 years ago
|
||
Made first attachement more "test-case-like" by reducing to only needed and
cleaning up html-source.
Reporter | ||
Updated•22 years ago
|
Attachment #114650 -
Attachment is obsolete: true
Comment 6•22 years ago
|
||
In the third testcase, the two cells in the first row are different heights (!).
That's the problem....
Reporter | ||
Comment 7•22 years ago
|
||
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•22 years ago
|
||
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....
Updated•22 years ago
|
Reporter | ||
Comment 9•22 years ago
|
||
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!?)
Reporter | ||
Comment 10•22 years ago
|
||
Validated using utf-8, HTML 4.1 Transitional
Reporter | ||
Comment 11•22 years ago
|
||
Validated using utf-8, HTML 4.01 Transitional
Reporter | ||
Comment 12•22 years ago
|
||
Downloaded Version 1.3. Bug still there.
Updated•22 years ago
|
Target Milestone: --- → Future
Reporter | ||
Comment 13•20 years ago
|
||
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.
Updated•20 years ago
|
Summary: Rowspan is not handled properly in conjunction with images → {inc}Rowspan is not handled properly in conjunction with images
Reporter | ||
Comment 14•19 years ago
|
||
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•19 years ago
|
||
If someone were working on this, the bug would be assigned to that person...
Reporter | ||
Comment 16•19 years ago
|
||
Looks like bug also appears for text-only, too.
Attachment #114671 -
Attachment is obsolete: true
Attachment #117474 -
Attachment is obsolete: true
Attachment #117475 -
Attachment is obsolete: true
Reporter | ||
Comment 17•19 years ago
|
||
(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•18 years ago
|
||
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•18 years ago
|
||
Janick, the testcases look ok to me in a trunk build... are you still seeing this bug on trunk?
Reporter | ||
Comment 20•18 years ago
|
||
The current trunk build is crashing on me. I will try to test again in a few days.
Comment 21•16 years ago
|
||
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•15 years ago
|
||
please reopen if you still see this bug and explain what is wrong
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•