Closed
Bug 235302
Opened 22 years ago
Closed 19 years ago
{inc}Adding cells with percent width incrementally to a table leads to broken layout
Categories
(Core :: Layout: Tables, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: olaf, Unassigned)
References
()
Details
(Keywords: testcase)
Attachments
(3 files, 2 obsolete files)
User-Agent:
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040116 Galeon/1.3.13
According to the standard, the "LINK" element should be only placed in <HEAD>
section.
If "LINK" is placed in other place, mozilla doesn't render page correctly.
In the example URL, the "LINK" is placed two times:
1. - correct in <HEAD>
2. - incorrectly in <TABLE>
Reproducible: Always
Steps to Reproduce:
1. Open the page http://www.lilith.pl/index_pl.php?page=mapa.inc
Actual Results:
Mozilla doesn't render page correctly.
Expected Results:
Mozilla should render page correctly. It shouldn't take this "LINK" occurence
under consideration.
This page looks ok in IE.
|
Reporter | |
Comment 1•22 years ago
|
||
I attache source of reported URL in case it is changed.
|
|
||
Comment 2•22 years ago
|
||
> Mozilla doesn't render page correctly.
Could you please clearly describe exactly how it renders incorrectly and what
the expected rendering is? Use the testcase you attached, not the original
page, please.
|
||
Comment 3•22 years ago
|
||
Attachment #142037 -
Attachment is obsolete: true
|
|
||
Comment 4•22 years ago
|
||
OK, I see what happens now - the <LINK> forces the table to layout at that
point. The same can be achieved with a <SCRIPT> ...
Attachment #142081 -
Attachment is obsolete: true
|
|
||
Comment 5•22 years ago
|
||
Confirming bug, 2004-02-20-08 trunk Linux.
Status: UNCONFIRMED → NEW
Ever confirmed: true
|
|
||
Updated•22 years ago
|
Summary: incorrectly placed "LINK" element causes wrong page rendering → {inc}Adding cells with percent width incrementally to a table leads to broken layout
Whiteboard: DUPEME
What's the *problem*? The gap between the top of the table and the cells, or
some mispositioning?
|
|
||
Comment 7•22 years ago
|
||
The problem is that the markup
<tr>
<td width="18%"><marquee>Marquee...</marquee></td>
<td>WWW.LILITH.PL</td>
</tr>
makes the second cell be shrink-wrapped width and the first cell as wide as it
can get. Or so I'm assuming...
|
|
||
Comment 8•22 years ago
|
||
The problem is that the table cell with the <marquee> is too wide.
The problem here is that the scroll frame returns the percent based width as MEW.
area 02B68788 d=12732,240 me=12732
scroll 02B687DC d=5964,240 me=5964 m=0
scroll 02B687DC d=5964,240 me=5964 m=0
block 02B68664 d=5964,240 me=5964 m=0
If you replace the marquee with a div you will see that it returns a content
based MEW as expected.
block 012BFA34 d=5964,240 me=804 m=804
block 012BF91C d=5964,240 me=804 m=804
cell 012BF8A8 d=6012,288 me=852 m=852
obviously the scrollframe MEW computation should get the same love as the
blockreflowcontext got with bug 39683
|
||
Comment 10•22 years ago
|
||
|
|
||
Comment 11•22 years ago
|
||
the code in question is at
http://lxr.mozilla.org/seamonkey/source/layout/xul/base/src/nsBoxFrame.cpp#895
|
|
||
Comment 12•19 years ago
|
||
All testcases works for me Firefox 1.5.*, 2.0 and trunk builds.
This was fixed between Mozilla 1.8a4 and 1.8a5 as far as I can tell.
There is a reflow branch regression on the testcases that I filed as bug 363333.
-> WORKSFORME
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•