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.
Created attachment 19278 [details] test case for this problem
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.
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.
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.
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.
Firefox does the same thing.
<rdar://problem/9473424>