Closed Bug 68499 Opened 24 years ago Closed 23 years ago

CSS1: Background-attachment:fixed buggy for elements other than BODY

Categories

(Core :: CSS Parsing and Computation, defect)

Product:
Core
Component:
CSS Parsing and Computation
Platform:
x86
Windows 98
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9

People

(Reporter: ian.graham, Assigned: roc)

References

(
URL
)

Details

(Keywords: css1)

Attachments

(2 files)

Changes to nsViewManager and nsHTMLContainerFrame
5.86 KB, patch
Details | Diff | Splinter Review
Better patch --- changes nsViewManager only
4.30 KB, patch
Details | Diff | Splinter Review 
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.
Keywords: css1
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
Assignee: pierre → roc+moz
Accepting
Status: NEW → ASSIGNED
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=?
Keywords: approval
sr=attinasi
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
This isn't actually fixed until the new view manager is turned on. Adding
dependence on bug 39621 and reopening.
Status: RESOLVED → REOPENED
Depends on: 39621
Resolution: FIXED → ---
Status: REOPENED → ASSIGNED
Target Milestone: --- → mozilla0.9
The new view manager is checked in and enabled, so this bug is now fixed.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → 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
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: