11660 - Clip should apply to child views

Status: VERIFIED FIXED

(Core :: Web Painting, defect, P2)

Description

[troy]

The "clip" that can be specified for a view should apply to the child views,
i.e. those child views outside of the clip rect should be clipped

The clip rect is optional, because it's usage by layout depends on the
'overflow' property. The default value is 'visible' which means that child
elements that extend outside their parent are visible. A value of 'hidden' means
that child elements that extend outside the parent are clipped

Comment 1

[Patrick C. Beard]

This is a feature bug. Probably not urgent, given that bug #10915 is in M13.
Deferring to M12.

Comment 2

[Patrick C. Beard]

On the other hand, child views may always be getting clipped to parent views by
the compositor. This should only happen if a clip rect is specified?

Comment 3

[troy]

Yes, clipping of child views should only happen if a clip rect is specified. If
no clip rect is specified, then the child views should be allowed to extend
outside of their parent and they should be visible and paint and get events

We rely on this behavior in layout, because that's the way CSS2 visibility works

Comment 4

[troy]

*** Bug 27602 has been marked as a duplicate of this bug. ***

Comment 5

[troy]

*** Bug 27735 has been marked as a duplicate of this bug. ***

Comment 6

[Robert Crawford]

So a container is not a container by default?
This will break a million pages.
A parent-container SHOULD clip it childern BY DEFAULT.
Otherwise, there is precious little point to it's parent status.
A container should "contain" - rather than simply be loosly associated with - 
it's children.

Comment 7

[Patrick C. Beard]

*** Bug 27602 has been marked as a duplicate of this bug. ***

Comment 8

[Patrick C. Beard]

Here's the right way to fix this:  we need to build a more persistent display 
list, that we keep around, which caches clipping calculations, etc. We don't want 
to have to recompute this each time we draw.

Comment 9

[troy]

*** Bug 30975 has been marked as a duplicate of this bug. ***

Comment 10

[troy]

*** Bug 30974 has been marked as a duplicate of this bug. ***

Comment 11

[Patrick C. Beard]

This requires a tree walk over children when nsView::SetClip() is called. To do 
this efficiently will take some thought.

Comment 12

[Kevin McCluskey (gone)]

Bulk moving to M16

Comment 13

[Kevin McCluskey (gone)]

Fixed in 4/13/2000 5:02 PM build.
Filed bug 35791 to cover the case where the view has a widget.

Comment 14

[Hixie (not reading bugmail)]

As per meeting with ChrisD yesterday, taking QA.

Comment 15

[Hixie (not reading bugmail)]

Attachment: Reference image for upcoming testcase.

Comment 16

[Hixie (not reading bugmail)]

Attachment: Testcase for behaviour, as best I can determine.

Comment 17

[Hixie (not reading bugmail)]

VERIFIED on Win2K Comm M18 trunk builds 2000090609 using testcase.

Mac and Windows don't work well with clip. See bug 51678.

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a35a23f1d20e
[fenix] For https://github.com/mozilla-mobile/fenix/issues/11660: added prefetch for topsites and update in onCreateView() (https://github.com/mozilla-mobile/fenix/pull/11668)
https://hg.mozilla.org/integration/autoland/rev/ff1809e4a0e2
[fenix] For 11660: fixing nits for previous https://github.com/mozilla-mobile/fenix/pull/11668 (https://github.com/mozilla-mobile/fenix/pull/11821)
https://hg.mozilla.org/integration/autoland/rev/dfc04a81e7dd
[fenix] Revert "For 11660: fixing nits for previous https://github.com/mozilla-mobile/fenix/pull/11668 (https://github.com/mozilla-mobile/fenix/pull/11821)"