231585 - semi-transparent, overflow:auto div-layer doesn't scroll and renders background image incorrectly when scrolling manually.

Status: RESOLVED FIXED

(Core :: Web Painting, defect, P2)

Description

[james]

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6) Gecko/20040113
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6) Gecko/20040113

I have a semi-tansparent (-moz-opacity: .7), overflow:auto and percentage height
div-layer that doesn't scroll, this is outlined in here 
http://bugzilla.mozilla.org/show_bug.cgi?id=97283 )

I was told to post this as a new bug because the same div-layer renders the
background image (assigned through the body element) incorrectly when scrolling
manually. The background image scrolls with the div layer when it should stay
fixed in the background (body element). When text is highlighted in the div
portion of the image behind the highlighted text is rendered correctly. The
image is rendered in the correct position when switching to another browser
window and back again.

In IE6 the bkg image is fixed behind the div layer and is rendered correctly.
I have a feeling this is due to the overflow: auto/scroll not focusing a div
layer correctly (see bug 97283).

james

Reproducible: Always

Steps to Reproduce:

Comment 1

[james]

Attachment: Sample html and css. Scroll down on the div layer to view the problem

Comment 2

[Boris Zbarsky [:bzbarsky]]

Seeing the garbage painted with Linux build 2004-01-15-07 too.

Comment 3

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

Attachment: slightly simplified testcase

This is a simplified version of James' test case.

Comment 4

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

Attachment: fix

The problem is that a view is being marked "painted on uniform background" when
its background is actually part of a translucent group and is therefore not
really uniform (all same pixel values). We need to detect when such a view's
background is part of a translucent group and stop OptimizeDisplayList from
treating it as opaque for the purposes of CanScrollWithBitBlt. That would be
hard because we don't know in the view system exactly where the uniform
background comes from (the nsGfxScrollFrame parent of the scrolled view, in
this case, which may not even have a view itself) but we can fall back to the
safe approximation of checking whether the HasUniformBackground() view itself
is translucent.

Comment 5

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

Comment on attachment 145446 [details] [diff] [review]
fix

This is getting a bit ugly. Maybe HasUniformBackground is not quite the right
piece of information to transmit to views.

Comment 6

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

One way to improve the situation would be to make nsGfxScrollFrame always have a
view of its own, and then have a view property IsUniformBackground() which is
set for any appropriate view (means: "the background is a solid block of the
same pixel value covering the entire view, AND this view paints no other content
of its own"). Then CanScrollWithBitBlt could discover the necessary optimizations.

Comment 7

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

Comment on attachment 145446 [details] [diff] [review]
fix

Very safe fix to visual corruption bug.

Comment 8

[chris hofmann]

Comment on attachment 145446 [details] [diff] [review]
fix

a=chofmann for 1.7

Comment 9

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

checked in