70446 - Content renders on top of scrollbars (viewmanager3)

Status: VERIFIED FIXED

(Core :: Layout, defect)

Description

[Adam D. Moss]

Enable the new 'scary' ViewManager on a recent build (tested
on the 2001-02-27 nightly build).

Visit the URL http://www.dark-legacy.net/silent-hill/index2.htm

Resize the width of the browser (to about 760 pixels) so that
the blinking 'PRESIDENT EVIL' animated GIF in the righthand
column of links overlaps the scrollbar.

This image will incorrectly draw *over* the scrollbars (and
also cause redraw confusion within the scrollbar frames).

This only occurs with ViewManager3 enabled, not ViewManager2.

Comment 1

[Adam D. Moss]

Attachment: Screenshot of undesirable effect.

Comment 2

[Boris Zbarsky [:bzbarsky]]

I see this on linux build 2001-02-27-21 as well.

Comment 3

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

I also saw something like this on bugzilla with a dropdown select for the first
time yesterday or today.  It seems similar to the very old bug 5195, but
occurring in more cases (perhaps due to some recent view manager change?).

Comment 4

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

Doh!

Comment 5

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

OK... The problem is my previous fix for bug 69146. It turns out that the result 
of nsIWidget::IsVisible can't be trusted. At least, for the ScrollFrame widget 
it returns "false" even though the widget is definitely visible. So the 
scrolled content doesn't get added to the opaque map when we paint the scroll 
container, and we paint the scrolled content again along with the container, 
which is really nasty in terms of performance.

Furthermore for some unclear reason when painting the scroll container, images 
in the scrolled content aren't always clipped correctly. I presume this is a 
rendering bug (usually concealed because the scrolled content is normally drawn 
in its own widget and therefore clipped by the windowing system).

Anyway, the fix is to ignore the widget visibility and look at the view 
visibility, which seems to be trustworthy. Also, instead of using the widget 
bounds and scaling them, it makes much more sense to use the view bounds. I will 
attach a patch to do this, but unfortunately I'm again in a situation where the 
patch supercedes a pending patch for a previous bug (bug 69346).

Comment 6

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

Attachment: The fix

Comment 7

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

This does what I said above ... basically, we ignore the widget data and use the 
view data instead. Works well in my build. Marc, Kevin?

Comment 8

[Kevin McCluskey (gone)]

patch looks good.
r=[e-mail]

Comment 9

[Marc Attinasi]

sr=attinasi

Comment 10

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

Fix checked in.

Comment 11

[Adam D. Moss]

Verified fixed.  Thanks!