5194 - border problems on overlapping fixed positioned elements

Status: VERIFIED FIXED

(Core Graveyard :: GFX, defect, P3)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The borders zig-zag on overlapping fixed positioned elements, and sometimes
text isn't drawn in the one that's on top in the area where another is
underneath.

Both problems are visible where the center and lower left elements in the above
test intersect.

Comment 1

[Patrick C. Beard]

-> M6

Comment 2

[Patrick C. Beard]

I have no idea what this page is supposed to look like. Can you provide a screen
shot of ideal behavior?

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The problem is on Windows 95 and *not* on Linux, so it's not XP.
The Linux (and maybe Mac) is what it's supposed to look like.

Screenshot of Win95 behavior to be attached.

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: screenshot of problem on Win95

Comment 5

[Hixie (not reading bugmail)]

It's not just borders, AFAICT: Any area on that page where fixed positioned
elements overlap will have rendering errors (visible on my build as white
blocks, with inactive scroll bars). It might be related to bug 4209, bug 8489.

Comment 6

[Patrick C. Beard]

Does this happen on NT as well, or is it truly Win95 specific?

Comment 7

[Patrick C. Beard]

I see white blocks in the overlapping areas on NT.

Comment 8

[Patrick C. Beard]

Here's my latest theory of the problem:

After we create the widgets in layout, on windows (& X?) we need to ensure that
the sibling z-order of the child windows agree with the z-order of their views,
because it's creation order dependent. I believe that layout isn't creating the
widgets in the proper order, whereas the display list is created in the correct
order. So, there's a mismatch between widget creation order and the display list.

The evidence for this is to turn turn off double-buffering and let the display
list control all clipping. A simplified version of the test case with only the
top two paragraphs looks correct. When double-buffering is turned on, full
widget-size blits occur, and incorrect results are observed.

The long-term fix for this bug is to stop using child windows so gratuitously --
especially since this will allow other types of composited effects to occur, such
as opacity < 1.0. Child windows should be relegated to plugins and other types of
rendering that we don't expect to take part in compositing.

Comment 9

[Hixie (not reading bugmail)]

Migrating from {css2} to css2 keyword. The {css1}, {css2}, {css3} and {css-moz}
radars should now be considered deprecated in favour of keywords.
I am *really* sorry about the spam...

Comment 10

[Patrick C. Beard]

OK, nsViewManager2 seems to fix this problem as well. However, GFX scrollbars are 
being drawn UNDER the top-right paragraph, so I've filed bug #26851.

Comment 11

[Patrick C. Beard]

Landed nsViewManager2.

Comment 12

[Alan S. Jones]

verified fixed.  Just now need to fix bug #26851 like mentioned above.