210657 - percentage height div (overflow:auto/scroll) in table should be scrollable but isn't

Status: NEW

(Core :: Layout, defect)

Description

[Anthony Sciola]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030617
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030617

A (rather large :( ) attachment will be included to demonstrate the bug.

Basically, the div table should have a fixed size and, with enough elements to
exceed its height, become scrollable. On load, however, the table resizes itself
to display all the elements.

Reproducible: Always

Steps to Reproduce:
1. Load the included HTML.
Actual Results:  
Table resized to display all items.

Expected Results:  
Table should have displayed only those which would fit inside its designated
height and included a scroll bar to access the rest.

Up through Mozilla 1.2.1, the table displays with scrollbars. The issue appears
in at least the 1.3 final and all 1.4s (not sure about 1.3a or b).

The table is also scrollable in IE 6.

Comment 1

[Anthony Sciola]

Attachment: Attachment to display bug 210657 (non-scrollable table).

I apologize for the size of the HTML. I'm not 100% certain if the behavior is
through javascript, css, or html. This is a slightly different version of the
attachment for bug 210551.

Comment 2

[Mats Palmgren (inactive)]

"onload" (tabInit missing) and using the buttons produces JavaScript errors.
Can you please make a minimal testcase?

Comment 3

[Andrew Schultz]

Attachment: testcase

<table style="height: 100px;">
  <tr><td>
     <div style="overflow: auto; height: 100%;"> 
Items
     </div>
  </td></tr>	       
</table>

Mozilla 1.2.1 gives the <div> a scrollbar, current trunk extends the <div>'s
height.

Comment 4

[Andrew Schultz]

The behavior here switched between linux trunk 2003012722 and 2003012905,
indicating bug 189840.  Was the change here intended?

If the testcase's <table> is a <div>, it gets a scrollbar with current trunk.

Comment 5

[Mats Palmgren (inactive)]

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

Comment 6

[Mats Palmgren (inactive)]

Attachment: Testcase from bug 211211

Comment 7

[Mats Palmgren (inactive)]

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

Comment 8

[Mats Palmgren (inactive)]

Attachment: Testcase from bug 208249

Comment 9

[Mats Palmgren (inactive)]

The problem only occurs for percentage height elements in a table, so bug 189840
seems the likely cause for this regression.

Comment 10

[Bernd]

<table style="height: 100px;">
  <tr><td>
     <div style="overflow: auto; height: 100%;"> 
Items
     </div>
  </td></tr>	       
</table>

in strict mode the height for the inner div would be auto as specified in:
http://www.w3.org/TR/2003/WD-CSS21-20030128/visudet.html#propdef-height 
So the div height would be auto, it table cell should wrap around it and the
table height spec will be overwritten.


In quirks mode however one could expect that the containing block height is
bounded by the 100px height specified for the table.
In this case a quirky height computation would be necessary
http://lxr.mozilla.org/seamonkey/ident?i=CalcQuirkContainingBlockHeight
In order to avoid the performance hit usually it is called with a restriction to
the first level. The testcase here  assumes that the block would climb up to see
that the table height spec. applies.

Comment 11

[Anthony Sciola]

It sounds like, in strict mode, the table/div combination is exhibiting the
correct behavior. If so, what is the proper way to get the desired scrolling effect?

Comment 12

[Bernd]

put the height spec on the containing <td>

Comment 13

[Anthony Sciola]

I tested Bernd's response (putting <td style="height: 100px;">) in the sample
case and then the sample case does work. The problem is, doing:

<table style="height: 100px;">
  <tr><td style="height: 100%;">
...

or

<table style="height: 100%;">
  <tr><td style="height: 100%;">
...

still fails. In both cases (using 1.4), the table resizes to fit all the items,
ignoring either its pixel height (in the 1st case) or the window height (in the
2nd). In 1.2.1, they appear (what I'm assuming is) properly.

Comment 14

[Steven]

(I submitted a bug this week; its basically this one. So I will post here my
test results.)

Here is what I find interesting look at these two test cases I made:
Div style set to "overflow:scroll;height:100%;"
<a
href="http://www.lansports.net/pics/Test1.htm">http://www.lansports.net/pics/Test1.htm</a>

Div style set to "overflow:scroll;height:80%;"
<a
href="http://www.lansports.net/pics/Test1.htm">http://www.lansports.net/pics/Test1.htm</a>

notice the 80% div doesnt display all of its contents! But it does display most.

Comment 15

[Steven]

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

Comment 16

[Steven]

Sorry about the link mixup the 
100% link is:
http://www.lansports.net/pics/Test1.htm
80% link is:
http://www.lansports.net/pics/Test2.htm

Comment 17

[Sam Minnee]

I find this example HTML illustrates the problem quite well.  I don't know
anything about the engine internals, but it appears that when there is a %age
div inside a %age table:
 1) The table asks the div how much room it needs
 2) The div returns the height of the total scrollable area
 3) The table stretches out to accomodate this

At (2) the div should return something like "50% of my container TD size" to the
table.

<table border="1" height="100%" width="100%">
<tr><td>
<div style="width: 100%; height: 50%; overflow: auto">
<p>HELLO<p>HELLO<p>HELLO<p>HELLO<p>HELLO<p>HELLO<p>HELLO
<p>HELLO<p>HELLO<p>HELLO<p>HELLO<p>HELLO<p>HELLO<p>HELLO
<p>HELLO<p>HELLO<p>HELLO<p>HELLO<p>HELLO<p>HELLO<p>HELLO
<p>HELLO<p>HELLO<p>HELLO<p>HELLO<p>HELLO<p>HELLO<p>HELLO
<p>HELLO<p>HELLO<p>HELLO<p>HELLO<p>HELLO<p>HELLO<p>HELLO
</div>
</td></tr>
</table>

Comment 18

[Boris Zbarsky [:bzbarsky]]

So.. the key here is that the size of the div should not depend on its overflow
value.  It should be the same height no matter whether its overflow value is set
to "auto" or "visible".

Given that, what exactly is the bug here?

Comment 19

[Bob]

"So.. the key here is that the size of the div should not depend on its overflow
value.  It should be the same height no matter whether its overflow value is set
to "auto" or "visible".

Given that, what exactly is the bug here?"

The bug here is that Div tags with % height and overflow:hidden/auto/scroll have
dfferent display behavior when imbedded into a cell of a table than they do
naturally. When placed on the upper level a % height is interpreted as a % of
the client screen, but when in a table its % of the content contained within the
div tag. 

Comment 20

[Bob]

Sorry for commenting twice, I forgot one part. 

I dont know what the standard is, but I believe a div in a table with a % height
should be a % of the cell space, and not the content of the div.

Comment 21

[Boris Zbarsky [:bzbarsky]]

A div in a table with % heigh should be auto-height per the standard. None of
the testcases are testing standards mode, though, so that's irrelevant.

If you can attach a testcase clearly showing the discrepancy between div
behavior in tables and not in tables, that would be much appreciated.  None of
the existing testcases do that.  Don't bother with the overflow part unless that
affects the div height (it should not).

Comment 22

[Bob]

Attachment: Div placed into a cell of a table.

Here is a testcase of a div placed in a cell. Posting div not in cell next.

Comment 23

[Bob]

Attachment: Div not placed into a cell of a table.

Comment 24

[Bob]

I dont know if anyone is seeing this(might just need to reboot) but when I open
up    divincell.htm on my computer it displays wrong, if I middle click the link
to the attachment(opening up into a new tab) it displays wrong, but if I single
click the link it displays right. 

Comment 25

[Boris Zbarsky [:bzbarsky]]

Yep, makes sense.  The quirk is that for 100% content in auto-height parents we
walk the parent blocks till we find a non-auto-height one.  In the table
testcase, the table cell is _not_ a block, so we stop when we get to it and the
div ends up with a height of auto.  That's exactly what we want the behavior to
be, as it happens -- it gives decent compat with whatever it is IE does and is a
pretty simple heuristic to apply.

Note that overflow is totally irrelevant here -- if you just put a border around
both divs and remove the overflow properties you will see what's going on.

The reason behavior was different in 1.2.1 is that 1.2.1 was buggy wrt to sizing
of overflowing elements; it would change the size when you set overflow on an
element; then we fixed that bug.

I suppose we could try to adjust the 100% height quirk somehow. That would
require someone to come up with a very detailed analysis of how IE treats
percent-height divs inside table cells, as a start.

Comment 26

[Daniel Wang]

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

Comment 27

[Daniel Wang]

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

Comment 28

[Mats Palmgren (inactive)]

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

Comment 29

[Matthew Cheale]

I've just been looking at this very issue myself, what I found was you have is
three situations.

1) 
table height 100%
tbody height 100%
td height 100%
div height 100%

div asks td it's size, td asks tbody it's size, tbody asks table it's size table
asks viewport it's size.

Result: td and div endup the height of your screen.

2) 
table height 100%
tbody height undefined
td height 100%
div height 100%

div asks td it's size, td asks tbody it's size, tbody says undefined.

Result: td height is based on it's contents, that of the div.

3) 
table height 100%
tbody height undefined
td height undefined
div height 100%

div asks td it's size, td is undefined

Result: td height is based on it's contents, that of the div.


* What IE & Opera do
table height 100%
tbody height undefined
td height 100%
div height 100%

div asks td it's size, td asks tbody it's size, tbody returns undefined

Result: td's height is calculated as the total table size, equal to the view
port, less the other rows.

Comment 30

[Boris Zbarsky [:bzbarsky]]

Comment 29 is incorrect.  I'll post testcases demonstrating this.

Comment 31

[Boris Zbarsky [:bzbarsky]]

Attachment: Testcase showing item 2 in comment 29 is incorrect

Mozilla renders the div at the height of the viewport (minus the body's
margins).

Comment 32

[Boris Zbarsky [:bzbarsky]]

Attachment: Testcase showing item 3 in comment 29 is incorrect.

Again, Mozilla renders the div at the height of the viewport (minus body
margins).

Comment 33

[Matthew Cheale]

Attachment: Div with scroll within table.

Apart from those attachements have no divs.  This attachement demonstrates what
happens if the tbody exists with a height of 100%.  The TD becomes the height
of the viewport, rows scroll off the screen and the DIV in constrained and
therefore scrolls.

Comment 34

[Matthew Cheale]

Attachment: Div withinout scroll within table

This attachement demonstrates what happens when the tbody's height in
undefined.  The TD size becomes defined by it's content and hence the DIV is
not constrained, therefore not scrolling.

Did I misread the original intent of this bug?

Comment 35

[Boris Zbarsky [:bzbarsky]]

> Apart from those attachements have no divs.

You're right.. I was looking at files on one machine and attaching them from
another one.  They just had your code from comment 29, with a background on the
div to make it clear what the size is.  Note that that code does NOT have
overflow set.

> Did I misread the original intent of this bug?

I don't believe you did -- it's asking that the attachment in comment 34 be
rendered like that in comment 33.

Comment 36

[John Roden]

Attachment: Example of strange HEIGHT behaviour

This example show behaviour which seems to be what is 
desired in the discussion above.  It's achieved by setting 
STYLE="HEIGHT: 0" on the containing table cell.  The example
is from Bug 255367 which is probably a dupe of this one.

Strangely, setting the HEIGHT="0" does NOT work.

Please don't lose this behavior! -- it's very useful altho'
it would be better if HEIGHT=100% did the same job.

Comment 37

[Lambertus Gorter]

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

Comment 38

[Ralf Vitasek]

this is the same as bug 216847

please someone scrap either this bug or the other as a duplicate.
so that someone can move on to get this bug at least confirmed.

please! this bug is filed dozens of times since 2003 and none is confirmed or being worked on.

thanks!

Comment 39

[Kevin Hendrix]

Attachment: further example

shocked to see this bug is still alive and well in 2007 ... more than 4 years after it's creation.  here is an example of how this bug is alive and well today.

in essence, it renders the use of a div with overflow inside a dynamically sized td completely useless in a crossbrowser environment.

my example contains a TABLE sized to 100% height and 2 TR elements each with 1 TD element sized to 35% and 65% height respectively.  each TD has a DIV child sized to 100% height, with 'auto' overflow, and enough content to overflow the parent DIV vertically.

the result, as near as i can follow, is that the TD is basing it's vertical size on the contents of the DIV ... even though the DIV wants to maintain it's own overflow.  view the sample HTML in both moz/ff and ie to see the rendering difference.  i believe ie renders this "correctly".

more in followup example...

Comment 40

[Kevin Hendrix]

Comment on attachment 231965 [details]
further example

shocked to see this bug is still alive and well in 2006 ... more than 3 years
after it's creation.  here is an example of how this bug is alive and well
today.

in essence, it renders the use of a div with overflow inside a dynamically
sized td completely useless in a crossbrowser environment.

my example contains a TABLE sized to 100% height and 2 TR elements each with 1
TD element sized to 35% and 65% height respectively.  each TD has a DIV child
sized to 100% height, with 'auto' overflow, and enough content to overflow the
parent DIV vertically.

the result, as near as i can follow, is that the TD is basing it's vertical
size on the contents of the DIV ... even though the DIV wants to maintain it's
own overflow.  view the sample HTML in both moz/ff and ie to see the rendering
difference.  i believe ie renders this "correctly".

more in followup example...

Comment 41

[Boris Zbarsky [:bzbarsky]]

> shocked to see this bug is still alive and well

The problem is that it's not actually clear that it's a bug per the current CSS spec...  See my earlier comments in the bug.

Comment 42

[Kevin Hendrix]

Attachment: further example #2

still trying to figure out why i thought it was 2007... 

this example changes the height of each child div to 50% rather than 100%.  as it renders in moz/ff, the height of each TD is still based on the height of the "contents" of the child DIV ... however the height of the actual div is based on the height of the TD ... it produces an poor result when rendered.

i think this is addressable with a single rule: don't base the height of a TD on the contents of overflow controlled child container.

Comment 43

[Ralf Vitasek]

@Boris: you're right about the current css specs. but ayn web developer that comes across this issue will say that this spec is stupid and useless the way it's written, and the way MS implemented it into IE is the only useful thing.

it's a shame this issue won't get fixed for 2.0 either.

@ian hixie: please what are the reasons for not fixing this?
i'd love to have a discussion about this issue on IRC. or maybe discussing it on a  suitable newsgroup.

PLEASE! we really need to work this out ASAP!

Comment 44

[Boris Zbarsky [:bzbarsky]]

If you have a problem with the CSS spec, please send mail to [e-mail] explaining the problem (and hopefully proposing alternate spec text).

Comment 45

[Kevin Hendrix]

Interestingly, the CalcQuirkContainingBlockHeight method commented on by Bernd in #10 above makes specific allowance for frames... "  *  When we encounter scrolledContent area frames, we skip over them, since they are guaranteed to not be useful for computing the containing block."

Sure enough an iframe in the same context does not exhibit the same layout deficiencies.  That sounds like a great place to add a patch ... thus allowing developers to choose either quirky useful formatting or strict spec formatting in their DOCTYPE definition.

Logically, whether an iframe with implicit overflow control or a div with explicit overflow control, both are simply blocks when calculating container block heights.  I would expect both blocks to flow the same in quirky render mode, just as I would expect both to flow the same in strict render mode.

Comment 46

[Boris Zbarsky [:bzbarsky]]

> When we encounter scrolledContent area frames

Frame is the term for "layout object" in Gecko.  Think "box" in CSS.  No relationship to iframes (other than that the layout object for an iframe is an nsSubDocumentFrame).

> both are simply blocks when calculating container block heights.

An iframe is a replaced inline by default.

Comment 47

[Frederid Palacios]

Attachment: DIV overflow doesn't scroll

This is a typical example, check vs. Internet Explorer 6+ to see the behavior.  The DIV doesn't show any scrollbar and the render isn't correct in Firefox.

Comment 51

[myshelter]

I think this is the bug I am (still) getting in Firefox 3.5.2.

I ran into it when trying to place a large image inside a scrollable div, which in turn is inside a table cell. It doesn't matter how many nested containers there are, as long as they are all within a table cell. Instead of the div being scrollable, the image deforms the whole containing layout if it's too small, this in standards mode. IE7+ render this correctly (although IE7 always displays both scrollbars even when the div content only overflows in one direction).

Comment 53

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 11 duplicates.
:dholbert, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 54

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.