It appears that background-attachment: fixed works on elements that are descendents of BODY _only_ if BODY itself takes a fixed background. If BODY does not have fixed background (i.e, no background or a scrolling one), then the fixed background of a descendant does not scroll, and is in fact "smeared" if it is scrolled past the upper and lower viewport boundaries. The referenced URL (http://www.java.utoronto.ca/NS5-bugs/attach.html) links to three example document illustrating this behavior. The expected behavior is that a background with background-attachment:fixed should be fixed independent of the background properties of other elements. This bug was observed in Mozilla 0.7 [Build: 2001010901] Note: This bug is likely related to previously fixed bug 40217: "CSS1 background-attachment:fixed does not fix the background" (http://bugzilla.mozilla.org/show_bug.cgi?id=40217)

I don't see any smearing - I just see the background not being fixed. Perhaps that's because I'm using roc's new viewmanager.

I see smearing.

But I'm using a pretty old build. Hmm.

OK, new build. The image is actually drawn in the correct fixed position if you force an expose ... it's just not redrawing at the appropriate time.

OK, this is happening because the DONT_BITBLT flag is set on the view for the inner block element, but since the scrolling is being done by the body block element, it sees that its own DONT_BITBLT flag is not set and happily bitblts. The solution is to make a widget for background-attach: fixed elements.

OK, I have a patch. The patch makes nsViewManager respect DONT_BITBLT flags set on any child (widget-bearing) view of the view being scrolled. We still use fast platform scrolling for the scrolled widget, but we make sure to invalidate any children which have DONT_BITBLT set. The patch also forces the view for a "background-attachment: fixed" frame to have a widget. Reviews, etc, welcome.

Stealing bug

Accepting

Would invalidating the descendants (or did you really mean children?) with DONT_BITBLT without forcing views for 'background-attachment: fixed' elements to have widgets fix the problem? What are the disadvantages of making them have widgets? (What views have widgets right now?) I think (although I"m not sure) that I remember comments from when 'position: fixed' was originally implemented that it would have been nicer not to require widgets for 'position: fixed'.

I mean "descendants". We might have a situation where none of the immediate child views have DONT_BITBLT but some of their children do. Hmm. I thought I had a good reason to make them widgets but I can't think of it now :-). It should be doable without special widgets. I'll try.

That should do the trick! Now let's get the patch in before it rots.

patch looks good. r=kmcclusk@netscape.com minor nit: shouldn't aRepaintOnlyUnbittableViews be called aRepaintOnlyUnblittableViews?

Er, yeah. I'll check in the correct spelling.

Hmm, who should be the super-reviewer? What's buster's status?

buster has left the building well, mostly. anyway, waterson is your source for sr. attinasi should get sr privelages, if he hasn't already.l

roc: dude. 4 days from bug filing to awaiting sr=. you rock! :-) attinasi/waterson: can we have an sr=?

sr=attinasi

Fix checked in.

This isn't actually fixed until the new view manager is turned on. Adding dependence on bug 39621 and reopening.

The new view manager is checked in and enabled, so this bug is now fixed.

Verified fixed in 30/March nightly build (build 2001033020). However, I note that when only the background of a non-body element is fixed, as in http://www.java.utoronto.ca/NS5-bugs/bg-attach-ponly.html, then the fixed background 'jumps' vertically a bit when the page is scrolled. So it works, but there's some redraw problem affecting this case.

There are many situations where we get jumpy redraws. Here it's because we first do a screen-to-screen bitmap copy for fast scrolling, then we do a redraw to fix up the display. In other situations, it's because updating the screen requires repainting of more than one widget, which can only be done one widget at a time. (This latter one is particularly noticeable with fixed-position elements.) Fixing these would require a significantly different rendering architecture with 1) minimal usage of native widgets, preferably one widget per page and 2a) platform support for copying bits from the screen to an off-screen rendering buffer or 2b) explicitly retaining the rendered bits for each page in an off-screen buffer so we can copy from them later On some platforms we might be able to arrange for some sort of synchronized update of a lot of native widgets at once, including scroll operations, but I don't even know how to do that for Windows, let alone the platforms I'm less familiar with. In other words, this is a tough one.

Robert: 2b would fit in very well with the proposed fix for bug 65701.

I can see how this is a tough problem. But it's clear that the performance hit relative to platform-specific renders (IE, etc.) can be significant, and thus a real impediment to use of Mozilla-based products on slower hardware. It's also an easy 'club' with which Mozilla will be bashed by a certain Unnamed Browser Vendor ;-) So, performance analysis and re-engineering is probably called for, although I wouldn't hazard a timeline for it.

VERIFIED using the provided test cases