76698 - Container frames do not size their views to encompass their children's views for absolute and relative positioned frames

Status: RESOLVED DUPLICATE of bug 131475

(Core :: Web Painting, defect, P1)

Description

[Kevin McCluskey (gone)]

Comment 1

[Kevin McCluskey (gone)]

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

Comment 2

[Kevin McCluskey (gone)]

This bug was discovered while investigating bug 69075

Comment 3

[Kevin McCluskey (gone)]

Using the test case in bug 69075.

Place a window over the lower yellow block. 
Expose the browser window by clicking on the title bar.
Result: The yellow block is not redrawn

Comment 4

[Kevin McCluskey (gone)]

During the construction of the display list in nsViewManager::CreateDisplayList 
it explicitly checks to see if the view overlaps the damage rect. If it does not 
overlap the damage rect it does not cycle through its child views to determine 
if they overlap the damage rect. (The old viewmanager checked the children 
regardless of whether the parent view interesected the damage rect)

Since parent views are not required to contain their child views, a child views 
rect may lie completely outside the the parents rect and intersect the damage 
rect while the parent view does not intersect the damage rect.

Comment 5

[Kevin McCluskey (gone)]

Attachment: Patch which removes the explicit check for overlap and fixes this bug

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

> Since parent views are not required to contain their child views

Yes, they are. Layout has code that is supposed to ensure this.

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Well, actually the rule is that non-clipping views must contain their child 
views. But there is tons of logic to a) guarantee this and b) relies on this.

Comment 8

[Kevin McCluskey (gone)]

Hmmm, when troy was around he insisted that view system must allow views to NOT
be contained by their parent.  He was adamant that the layout system needed to
work that way because this was the model that CSS required.

It sounds like we have a case were most of layout assumes/maintain containment
and a few other parts don't.

Robert can you give me a pointer to areas in layout which assume/maintain view
containment?  

We need to clear up this issue and decide what the invariant is. 

View containment does imply that there will be pathological cases such as when a
parent view located in the upper left corner of the window with a child view in
the lower right causes the parent view to be be repainted for virtually every
damage rect. 

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

nsContainerFrame::SyncFrameViewAfterReflow says

> // If the frame has child frames that stick outside the content
> // area, then size the view large enough to include those child
> // frames
> if ((kidState & NS_FRAME_OUTSIDE_CHILDREN) && aCombinedArea) {
>   vm->ResizeView(aView, aCombinedArea->XMost(), aCombinedArea->YMost());

So it seems Layout wants a view's area to always include its frame and all the 
child frames. If the view includes all the child frames, then it must also 
include all the child views ... right?

I think we already had this discussion in the bug about views with frames that 
extend above or to the left of the parent frame. I thought the conclusion there 
was "It is the responsibility of Layout to always create view hierarchies in 
which a non-clipping view contains the areas of all its child views".

Comment 10

[Andreas M. "Clarence" Schneider]

I see this bug only if the yellow block is covered by the context menu, works
for me with any other window. A similar behavior can be seen with
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=30748 (bug 75882).
2001-05-12-08, Win NT.

Comment 11

[Kevin McCluskey (gone)]

Moving to Mozilla0.9.6

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Kevin, we need to resolve this issue because it's blocking my work on other
bugs. In light of the discussion here and in bug 13213, can we mark this bug
INVALID and agree that Layout will ensure all views contain their children?

Comment 13

[Kevin McCluskey (gone)]

I discussed the issue with attinasi,karnaze, waterson, and dbaron and we've
agreed to the invariant that layout will ensure all views contain their children. 

There is still a bug in layout which the testcase in bug 69075 exposes. How
about we change the description of this bug to cover the layout bug?

Comment 14

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Yes, that sounds like a good plan.

Comment 15

[Kevin McCluskey (gone)]

Bulk moving Mozilla1.01 bugs to future-P1. I will pull from the future-P1 list
to schedule bugs for post Mozilla1.0 milestones

Comment 16

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I don't think we have any non-working testcases anymore, now that 69075 is fixed.

Comment 17

[Malcolm Rowe]

roc: bug 69075 wasn't fixed - it was marked WORKSFORME because people couldn't
reproduce the original problem.

I can still (1.1) reproduce the behaviour described in this bug in comment 3
(but you must ensure the window isn't over the *red* frame) and comment 10
(context menu over the yellow frame does not repaint correctly).

Essentially, it looks like if you cause the red frame to repaint, the yellow
frame will also repaint, but the yellow frame won't repaint by itself, which
makes sense, I guess.

A similar/identical(?) problem is mentioned in bug 131475.

REOPENING - please hit me if I misunderstood something.

Comment 18

[Malcolm Rowe]

Related? bug 66147
Dependent? bug 46983

Comment 19

[Robert O'Callahan (:roc) (email my personal email if necessary)]

This is a bug related to relative positioning, which we already have filed in
several different variations ... 131475 is a good one.

*** This bug has been marked as a duplicate of 131475 ***