If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

tables not expanding in the right places, etc...

VERIFIED DUPLICATE of bug 19961

Status

()

Core
Layout: Tables
P2
normal
VERIFIED DUPLICATE of bug 19961
18 years ago
18 years ago

People

(Reporter: stew777, Assigned: karnaze (gone))

Tracking

Trunk
x86
Windows 98
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [TESTCASE], URL)

Attachments

(4 attachments)

(Reporter)

Description

18 years ago
Hi! This is my first bug report so I hope I'm doing it right... I'm developing a website (you can see a beta at http://www.angelfire.com/ut/ptest/) and it renders pretty closely on Netscape and IE (with the exception ofcourse of Netscapes limited CSS support). However, it's just a mess in Mozilla (I'm using M12). The two main problems are 1. At the top of the pages there ae a bunch of nested tables that make up the title/banner add section. Only two tables in the whole "assmebly" have a 100% value, the outside one and one near the right hand side. You would expect then for the outside table to resize to the width of the screen and the other table with the 100% value to expand inside of it, making up the room. This is exactly what happens in IE and Netscape but not Mozilla (try it out). I hope you can fix this (it seems liek a serious bug to me). The other, less serious problem, is that there is a large ammount of space between the two rows of tables in the "nav" bar, as if there were a <p> tag or larger text somewhere. It shows up normally in IE and Netscape.

THANX!
Ryan Stewart
stew777@email.msn.com
(Reporter)

Comment 1

18 years ago
...sorry that didn't wrap for soem reason :)
(Reporter)

Updated

18 years ago
OS: other → Windows 98
(Reporter)

Updated

18 years ago
Priority: P3 → P2

Updated

18 years ago
Whiteboard: [MAKINGTEST] mielke@licel.com

Comment 2

18 years ago
Created attachment 5213 [details]
It reproduces the bug with nested table width

Comment 3

18 years ago
Created attachment 5214 [details]
It show another variant of the table problem

Comment 4

18 years ago
The problem seems to me to be related how the width arguments, are propagated in
 nested tables. For instance with pagetest2.html my favourite rendering is
produced by IE5 (I hate to admit that) It computes the width for the first two
cells and leaves the space to the third cell, where a width argument of 100%
leads to a complete expansion. The pagetest5.html also breaks with IE5 and
Netscape 4.6. The notes in the HTML specification are not very precise for me,
so I doubt wether it is really a bug or an unusual feature.
Whiteboard: [MAKINGTEST] mielke@licel.com → [TESTCASE]
(Reporter)

Comment 5

18 years ago
I hope you can fix it. It must be a bug as there doesn't seem to be any way 
around it. Even if I do it with all tables (eg: instead of cells with 100% 
values I make tables without cell width values, and then put a table with a 
100% value in that to make it expand) it will again work in IE but suprisingly 
not in mozilla or netscape.
(Reporter)

Comment 6

18 years ago
...I"ve heard, like you said, it could be a problem with the HTML specs not 
indicating wether it's 100% of the table or the page, but either way I think it 
should still work...

Comment 7

18 years ago
Created attachment 5341 [details]
Does'nt display tables correcty ( BI 2000211516 NT4 )

Comment 8

18 years ago
Another exemple in 'http://www.forbes.com/tool/html/00/feb/0216/featb.htm'
(Build ID 2000021516 NT4 )
joao

Comment 9

18 years ago
I just tested my testcases with Amaya, the rendering was also interesting. So
it seems to me that the nesting of tables is some tricky stuff.

Comment 10

18 years ago
Created attachment 5494 [details]
further_reduction_of_testcase

Comment 11

18 years ago
In the BasicLayoutStrategy.cpp there is a comment, which indicates that if more
space for the columns is available, the fixed width will be overwritten. So I
would call this a problem within the algorithm inherited from the Navigator
(doing the same), and no wonder that in the table test case, the width argument
is never used for table cells, so it is the typical case of:
Not tested not working.

Comment 12

18 years ago
Problem #2 looks invalid - looks the reason there are big spaces between the two 
table rows is that every other cell in the first row has a nested paragraph 
which has a top and bottom margin of 1em. This is creating the space. If you 
take the paragraphs out, the space is reduced. 

Working on problem #1.

Comment 13

18 years ago
Thanks, mielke@licel.com, for identifying this as a dup of bug #19961 - marking 
it so. In 1st testcase, the first cell of parent table is being extended beyond 
its 245px specificity.

*** This bug has been marked as a duplicate of 19961 ***
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → DUPLICATE

Comment 14

18 years ago
Verified dup of #19961
Status: RESOLVED → VERIFIED
(Reporter)

Comment 15

18 years ago
THANX! for the heads up on the paragraph thing. I didn't really notice them, 
and they aren't nesicarry if tables are working correctly :) If you or anyone 
cares you check out a cleaner version of the code, but with the same major 
heading bug, at http://www.paintball.org
You need to log in before you can comment on or make changes to this bug.