Bug 17488 – If either overflow-x or overflow-y value is not visible, Webkit will change it to auto

• Component: CSS
• Status: NEW

[johnnyding]

See attached test cause,   The first div has style: ""height:100px; overflow-y:hidden; overflow-x:visable; width:1px", which means the page author wants to make sure that the div box have hidden clipped content in y direction, but doesn't clip the content in x direction.  
In IE 6/7, Opera 9, I think they have correct behavior.
But in FireFox 2/3, Safari,  the overflow-y:hidden will cause the actual used value of overflow-x is auto, since the div's width is not long enough for creating horizontal bar, the content in x direction has been clipped.

The reason of this problem is if either overflow-x or overflow-y value is not visible, Webkit will change it to auto. then the element will be treated as having overflow clip property. See function CSSStyleSelector::adjustRenderStyle (file: CSSStyleSelector.cpp, line:1201) and function RenderBox::setStyle (file: RenderBox.cpp, line:110).

I did not see that The CSS 2(http://www.w3.org/TR/CSS21/visufx.html#propdef-overflow) and CSS3(http://www.w3.org/TR/2002/WD-css3-box-20021024/#the-overflow-x) specification have define the behavior just like webkit did. 

Is that a bug? Anyone can point me for this problem. The problem caused some contentz can't be displayed in webpages for some high traffic Chinese websites.

[johnnyding]

Created attachment 19278 [details]
test case for this problem

[johnnyding]

How about using 2 flags: m_hasOverflowXClip, m_hasOverflowYClip instead of using m_hasOverflowClip, then we can discriminationally deal with clipped content in either x or y direction.

[Faruk Ates]

The reason why your test case breaks is because it's spelled "visible" (not visable) — changing it to visible makes the JavaScript detect the property correctly.

Nonetheless, the behavior is still incorrect: adding a test case that shows this in a different way.

The combination of overflow-x: visible; overflow-y: hidden;  (or vice-versa) is a desirable combination and should behave exactly as it reads: elements expanding outside the containing "viewport" should only be rendered along the x-axis but not along the y-axis.

What doesn't get defined by the spec, however, is what happens to content that is outside _both_ x and y axes. Should elements always get clipped to exact rectangles? (by far easiest to implement) Which axis/setting gets precedence? Letting it be dependent on CSS property order AND allowing for non-rect rendering would be very tricky to implement I'm sure.

[Faruk Ates]

Created attachment 20270 [details]
Overflow-x/y visible/hidden testcase

The overflow-x: visible;  should mean that on the x-axis, the element should still be rendered. Instead, it is being treated as overflow-x: scroll.

[vituko]

Sorry

Until the patch comes, possible workaround : overflow-x:hidden + padding-right (scroll width) ...

... but the padding is seen in IE and Firefox, both work as expected. The behavior in Opera and Khtml is similar to Webkit.

overflow-x:visible also becomes auto in Firefox, but the vertical scroll width is computed and the box pushes its container without showing the horizontal scroll nor hiding some content.

[Simon Fraser (smfr)]

Firefox does the same thing.

[Simon Fraser (smfr)]

<rdar://problem/9473424>