Closed
Bug 239477
Opened 21 years ago
Closed 20 years ago
strange space apears after a table using font tag inside an align=right cell
Categories
(Core :: Layout: Tables, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: el_rulero, Assigned: hsaito54)
References
Details
(Keywords: testcase)
Attachments
(4 files)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040402 Firefox/0.8.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040402 Firefox/0.8.0+
a gap appears between the right side of the window and a table meant to be the
size of the window when a font tag is used inside a cell aligned to the right in
the last column of the table (see test case attachment)
Reproducible: Always
Steps to Reproduce:
1.load the test case page attached
Actual Results:
the page becomes wider than the window because the empty space added at the
right of the table
Expected Results:
the table shold fit perfectly in the window
|
Reporter | |
Comment 1•21 years ago
|
||
|
||
Comment 2•21 years ago
|
||
confirming: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7b) Gecko/20040402
you don't need to use a <font> tag, it also works with <b>, or invalid tags like
<zz>, <fon>, <fantastic>. >ou don´t need a closing tag. You can use multiple
tags. Closing tags don´t work.
Minimal testcase needs one tag, one char, one space:
<tr><td align="right"><myTag>M </td></tr> is showing the bug,
<tr><td align="right"></myTag>M </td></tr> is ok.
Status: UNCONFIRMED → NEW
Ever confirmed: true
|
|
||
Comment 3•21 years ago
|
||
changing the <x> tag to </x> kills the scrollbar, or changing the table border
to 3 or more.
<html><head><title>Bug 239477</title></head>
<body marginwidth="0">
<table border="1" cellpadding="0" cellspacing="0" width="100%">
<tbody><tr><td align="right"><x>M </td></tr></tbody></table>
</body></html>
|
||
Comment 4•21 years ago
|
||
This is probably a duplicate or at least dependency of a bug bz fixed by had to
back out a few months ago due to an editor regression.
|
|
||
Comment 5•21 years ago
|
||
previous testcase used a single, invalid <x> tag,
this one uses a valid <b></b> pair:
<tbody><tr><td align="right"><b>M </b></td></tr></tbody></table>
Letter M can be any letter, I prefer M.
One or more spaces between the letter M and the </b> tag generate a horizontal
scrollbar, and the spaces between letter M and </td> tag are not shown.
<b>M </b></td> generates scrollbar, <b>M </b> </td> also, <b>M</b> </td> not.
|
||
Comment 6•21 years ago
|
||
That was bug 132561. Marking dependency, but I'm not sure it's really related
here....
Depends on: 132561
|
|
Reporter | |
Comment 7•21 years ago
|
||
btw, this doesn't happen with Firebird 0.7:
Mozilla/5.0 (Windows; U; Windows NT 5.0; es-AR; rv:1.5) Gecko/20031007 Firebird/0.7
the problem was introduced lately, at most with rv:1.6
|
||
Comment 8•21 years ago
|
||
*** Bug 239888 has been marked as a duplicate of this bug. ***
|
|
||
Updated•21 years ago
|
Assignee: nobody → saito
|
Assignee | |
Comment 9•20 years ago
|
||
|
|
||
Comment 10•20 years ago
|
||
Subtracting from the combined area's width is wrong unless the combined area is
for a leaf frame. Is that guaranteed to be the case here? If so, comment; if
not, the patch is wrong.
|
|
||
Comment 11•20 years ago
|
||
The second piece you patch is for a leaf, but the first isn't. However,
RelativePositionFrames is called after TrimTrailingWhiteSpace, so you're
probably OK. Then again, this would all be easier if RelativePositionFrames
built up the combined area from scratch.
This seems reasonable, but I'd like roc's opinion.
|
|
||
Comment 12•20 years ago
|
||
Actually, though, I think this could break the case of trimming whitespace from
a relatively positioned inline acting as an absolute container, where the
absolutely positioned elements overflow the right edge of the inline.
> where the absolutely positioned elements overflow the right edge of the inline.
Yeah.
This whole area of code is horrible. I can't say for sure whether this patch is
correct or not.
Maybe Hideo could try modifying RelativePositionFrames to recalculate the
overflow area from scratch. That would simplify things a lot. Watch out for the
overflow area on relatively positioned spans, though; you'll need to distinguish
between the overflow due to absolutely positioned children and the overflow due
to overflowing inline children.
|
||
Comment 14•20 years ago
|
||
I dont see a scrollbar in attachment 45394 [details] with winxp seamonkey trunk 2004083008
(aka wfm)
|
||
Comment 15•20 years ago
|
||
*** Bug 249183 has been marked as a duplicate of this bug. ***
|
||
Comment 16•20 years ago
|
||
The testcases all WFM in 1.8a5.
|
|
Assignee | |
Comment 17•20 years ago
|
||
It seems that this bug is fixed by a patch of Bug 252771.
You need to log in
before you can comment on or make changes to this bug.
Description
•