Assuming I understand the spec correctly, it should be possible to clip absolute positioned elements when they spill outside a parent whose overflow is set to hidden, even if the block that sets overflow is not positioned. The following test case fails in Mozilla, and I believe it's a bug. dbaron or hixie, slap me around if I'm wrong please.

If I understand the description of the overflow property [1] correctly the clipping only occurs for content where the block is acting as a _containing block_ for it (as defined in [2]). [1] http://www.w3.org/TR/CSS2/visufx.html#propdef-overflow [2] http://www.w3.org/TR/CSS2/visudet.html#containing-block-details You can slap me too :-)

Yeah, I wonder if that is just unfortunate wording though.

--> roc.

I find this test case rather perplexing. What would be the correct behavior if overflow had been set to auto rather than hidden?

WinIE does clip the div FYI.

Comment: NEVER consult the CSS2 reference. It's out of date. CSS2.1 has quite a lot of changes especially in this area. http://www.w3.org/TR/CSS21/

Having said that, there is definitely a bug here in the view manager clipping logic, and I think I know where it is.

Here's the fix. We definitely have a bug; our view reparenting code is supposed to ensure elements are clipped according to the element hierarchy, not the view hierarchy, using ReapplyClippingInstructions, but in this case they just aren't. Applying this patch makes ReapplyClippingInstructions obsolete and fixes the bug.

If the WG decides that we need to do clipping differently then we just need to modify the logic in nsView::GetClippedRect with yet another patch. This patch should be applied no matter what.

BTW the patch inverts the sense of ancestorX/ancestorY because previously they were always negative and the backwards meaning was hurting my brain.

Comment on attachment 99010 [details] [diff] [review] Fix r=kmcclusk@netscape.com

Comment on attachment 99010 [details] [diff] [review] Fix sr=kin@netscape.com -- The formatting of this comment now looks odd, can we even out the lines and add the punctuation back? // Keep track of the view's offset - // from its ancestor. + // from its ancestor + // This is the origin of this view's parent view in the coordinate space of 'parentView' below

Sure, I'll fix that. Thanks.

Fix checked in.

The fix for this bug prevents http://www.drunk.nl/lab/bugzilla/ from rendering. See bug 154568.