280884 - [quirks]overflow:hidden is not applied properly in a <DIV> element inside a <TD> element.

Status: UNCONFIRMED

(Core :: Layout, defect)

Description

[octavio]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

The overflow:hidden style attribute is not applied properly in a <DIV> element
when its height content exceeds the height of the parent <TD> element. Notice
that the parent <TD> element have a percentage height. 

Reproducible: Always

Comment 1

[Boris Zbarsky [:bzbarsky]]

So what is the bug?  The testcase doesn't make it clear what the expected
rendering is, and the rendering I see looks correct to me....

Comment 2

[octavio]

(In reply to comment #1)
> So what is the bug?  The testcase doesn't make it clear what the expected
> rendering is, and the rendering I see looks correct to me....

Try to resize the firefox window - making the height smaller - the red area 
should decrease its height acording to the new height of the firefox window; 
if you resize the firefox window - making the height bigger - you will see 
that the red area increase its height according to the firefox window. I think 
that the layout engine should decrease properly the height of the red area. 

Comment 3

[Boris Zbarsky [:bzbarsky]]

When I make the window shorter in a current build (not the ancient 1.0), the red
area gets smaller....

Comment 4

[octavio]

Attachment: screen-shot that shows the height issue.

screen-shot that shows the height issue.

Comment 5

[Boris Zbarsky [:bzbarsky]]

So what is the issue?  The 1px overlap between the red and the bottom of the
viewport?

Comment 6

[octavio]

(In reply to comment #5)
> So what is the issue?  The 1px overlap between the red and the bottom of the
> viewport?

I'm using the current build. Notice that when you make the window very small 
the red-area is not resized properly, you can see it with the style margin 
property of the BODY (it is set to 10px). I think that the red area should be 
very small - when the firefox window is smaller - and it should respect the  
bottom margin style (currently it is not respected). I attach a screen-shot 
that shows when the window is smaller then it not resize the red-area 
properly. 

Comment 7

[Boris Zbarsky [:bzbarsky]]

The question here is one of quirks-mode behavior.... given that the table cell
should have auto height per spec and that so should the div, what should the
behavior in quirks mode be?

What we do right now is that we make the div be at least its intrinsic height
but allow it to scale up as needed.  Since the height of the table cell depends
on the height of the div (table cells can't overflow), it will not shrink past a
certain point.

Given that this is quirks mode, "what does IE do?"

Comment 8

[octavio]

This could be "quirk-mode behavior" but in the same resizing scenario, the 
browser is actually considering the right margin defined in the BODY and 
resizes the width of the Table properly but this is not happening with the 
height. I might be wrong but I would think the BODY takes precedence over the 
elements of the page. 

A more evident case with the same resizing issue occurs when the height of an 
IFrame is defined as a percentage as you can see in this example:

http://www.janusys.com/janus/mozilla/56.html

After the browser reaches a certain point, the horizontal scrollbar and the 
down arrow of the Vertical ScrollBar of the page in the IFrame is no longer 
accessible. This issue causes several navigational problems in sites using 
IFrames.

> Given that this is quirks mode, "what does IE do?"
The new image attached shows the difference between both browsers.

Comment 9

[octavio]

Attachment: screen shot 2

screen shot that shows the issue height.

Comment 10

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/