Clipping of absolute positioned elements doesn't work

RESOLVED FIXED

Status

()

RESOLVED FIXED
16 years ago
16 years ago

People

(Reporter: hyatt, Assigned: roc)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: WG: should overflow apply to all descendants?)

Attachments

(2 attachments)

(Reporter)

Description

16 years ago
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.
(Reporter)

Comment 1

16 years ago
Created attachment 98915 [details]
Patch that demonstrates clipping bug.

Comment 2

16 years ago
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 :-)
(Reporter)

Comment 3

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

(Reporter)

Comment 4

16 years ago
--> roc.
Assignee: attinasi → roc+moz
(Reporter)

Comment 5

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

Comment 6

16 years ago
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.
Whiteboard: WG: should overflow apply to all descendants?
Created attachment 99010 [details] [diff] [review]
Fix

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 13

16 years ago
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
Attachment #99010 - Flags: superreview+
Sure, I'll fix that. Thanks.
Fix checked in.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
The fix for this bug prevents http://www.drunk.nl/lab/bugzilla/ from rendering.
See bug 154568.
You need to log in before you can comment on or make changes to this bug.