Closed Bug 5194 Opened 26 years ago Closed 25 years ago

border problems on overlapping fixed positioned elements

Categories

(Core Graveyard :: GFX, defect, P3)

x86
Windows 95
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: dbaron, Assigned: beard)

References

()

Details

(Keywords: css2, verifyme, Whiteboard: Fixed by nsViewManager2.)

Attachments

(1 file)

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.
Assignee: michaelp → beard
Target Milestone: M6
-> M6
Status: NEW → ASSIGNED
Target Milestone: M6 → M7
QA Contact: 4144 → 4110
Target Milestone: M7 → M9
I have no idea what this page is supposed to look like. Can you provide a screen shot of ideal behavior?
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.
Attached image screenshot of problem on Win95 (deleted) —
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.
Does this happen on NT as well, or is it truly Win95 specific?
I see white blocks in the overlapping areas on NT.
Target Milestone: M9 → M10
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.
Target Milestone: M10 → M13
Summary: border problems on overlapping fixed positioned elements → {css2} border problems on overlapping fixed positioned elements
Keywords: css2
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...
Target Milestone: M13 → M14
Summary: {css2} border problems on overlapping fixed positioned elements → border problems on overlapping fixed positioned elements
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.
Whiteboard: Fixed by nsViewManager2.
Landed nsViewManager2.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Keywords: verifyme
verified fixed. Just now need to fix bug #26851 like mentioned above.
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: