42543 - Quirk: table % height (w/i block) should be rel. to viewport

Status: RESOLVED DUPLICATE of bug 85016

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

Description

[Linda Baliman]

From Karl-Heinz Dahlman, Ticket Online sidebar tab developer:
Sometimes NS6 stretches tables in height, but it shouldn't do that. 
I send you two screenshots named NS6_table_error and NS46_table_ok. 
So you can verify the browser output. 
This touches screen design and you can choose any event from our 
database and if you select the name and the date/time you see the page 
with the prices which is displayed wrong with NS6. 
You can also verify the title "Klassik" in the topper right corner. 
This is a table too and is displayed out of the frame (cutted). 
We are talking about 10 or 20 pixel in height of a table cell. 
If you have a table with about 10 rows this is in summary about 
100 to 200 pixel. Too much I think. 
I don't know, why sometimes tables are displayed correct. 
If you verify our production list our our eventlist (also in tables) you will 
find 
that the display output is similar to NS46. (ans also NS47).

Comment 1

[Linda Baliman]

Attachment: NS 6 Table Error

Comment 2

[Linda Baliman]

Attachment: NS 46 Table OK

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I'm unable to test this (I think, assuming I'm seeing correctly how to get to 
the frame shown, which isn't completely clear from the images), due to bug 
42776.

A link to the frame showing the problem would allow this bug to be handled 
faster...

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Steps to find a frame with a table as shown:
 * load http://www.ticketonline.de/
 * click a category (e.g., "Klassik") on the left
 * pick a region (e.g., 3) in the map
 * pick one of the items in the list
 * pick one of the dates in the list
This shows a page like the one shown.

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: my screenshot (both browsers), showing few table differences (PNG)

Comment 6

[Linda Baliman]

More from Karl-Heinz Dahlmann--

Well I can't give you a steady link because
content is changing in our site but you may
try to click on "Chiemsee Reggae Summer" or
try any other single event. If you see a list with different dates
please select an additional date and you are right there.
I hope that helps. Just try this in NS6 and in NS47 and see
the difference. Thanks.
The site link is "http://www.ticketonline.de". Have fun !

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The screenshot shown is in a build of the browser from March.  Bugs from builds 
that old are, in most cases, not too useful unless they're checked on a more 
recent build first.

However, there are other problems shown on the page, so I'm assigning this to 
myself to figure out what they are, and get them filed correctly before marking 
the tables issue here as worksforme (since I assume it's been fixed sometime 
since March -- see the screenshot I've posted).

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: testcase for remaining problem

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The only problem left that I see is a table problem.  In 4.x, a percentage 
height on a table worked as a percentage of the viewport even if the table was 
inside a block (in the case of the page here, a FORM).

Giving this to karnaze to see what he thinks.

Comment 10

[Linda Baliman]

More from Karl-Heinz:
Regarding this problem I send you a screen shot of the NS 46 
and the NS6 PR1 - german version. 
The NS6 PR 1 german was downloaded in beginning of may. 
It's the latest version I have. 
If the problem is solved in the actual build (I can't check this because 
I don't have it) it's okay. Maybe you can test this easily. 
Just choose an event, a date and you will see how the tables are displayed. 

Note to Karl-Heinz:
I cannot get you a DE build at the moment, but please use the En-US Mozilla 
builds for testing in the meanwhile:
http://www.mozilla.org/projects/seamonkey/release-notes/

Comment 11

[karnaze (gone)]

Eric, can you fix the table/iframe height code in the reflow state to not give 
up when it encounters a block ancestor that is not the body. I think we 
discussed this, and you wanted iframes to work this way as well. If you take 
this and fix it, please run the table regression tests.

Comment 12

[Eric Pollmann]

I'll take a look at this and see if it causes any other regressions!

Comment 13

[Eric Pollmann]

This bug has been marked "future" because the original netscape engineer working 
on this is over-burdened. If you feel this is an error, that you or another 
known resource will be working on this bug,or if it blocks your work in some way 
-- please attach your concern to the bug for reconsideration.

Comment 14

[Bernd Mielke]

*** Bug 48043 has been marked as a duplicate of this bug. ***

Comment 15

[Charles Capps]

Additional comments from bug 48043 (see above for link) - <center> tags appear 
to be a trigger for this bug.  Using <div align="center"> instead of <center> 
has no impact.

Comment 16

[Karl Ove Hufthammer]

There *is* no 'height' attribute on the 'table' element, and it should 
therefore be ignored.

Comment 17

[jsp]

This behavior is dependent on the document type. If no doctype is specified,
<table height="100%"> works (at least if the table is a child of the body; I
haven't tried other cases). Setting the height with CSS (<table style="height:
100%">) also works. However, if the doctype is XHTML, neither works.

Comment 18

[jsp]

Attachment: No doctype, height attribute set. Works. (Borrowed from bug 48043.)

Comment 19

[jsp]

Attachment: No doctype, CSS height property set. Works.

Comment 20

[jsp]

Attachment: Doctype = XHTML, height attribute and CSS height property both set. Does not work.

Comment 21

[Eric Pollmann]

Yes, that's exactly right  :)  When no doctype is specified, we interpret the
page loosely, using "nav quirks mode", which causes some things to lay out more
like the 4.x generation of browsers laid them out, but violates the w3c specs.
However, when the doctype is specified as strict html (or xhtml), we will follow
the specs.

The percentage height of a table is relative to the containing block and not to
the viewport according to the w3c specs, so we can't size it that way if author
also specifies a strict dtd.

However, in the original testcase for this bug, this is not the case, it looks
"bad" with no doctype:
  <div>
    <table height=95%>...

So this bug is really just a compatability issue, and the issue of <table
height=100%> not being relative to the viewport with a strict dtd is a case of
the standard saying that is the way it should be.

FWIW, the quirks mode sizing code is here:
http://lxr.mozilla.org/seamonkey/source/layout/html/base/src/nsHTMLReflowState.cpp#1302
...and is only called if no dtd is specified.  :)

Comment 22

[Amarendra Hanumanula]

QA contact update

Comment 23

[karnaze (gone)]

The 4th attachment will be fixed with the patch to bug 85016.

Comment 24

[karnaze (gone)]

After realizing that the attachments after the 4th are not bugs, I'm marking 
this a dup of bug 85016.

*** This bug has been marked as a duplicate of 85016 ***