Closed Bug 1045 Opened 26 years ago Closed 25 years ago

CSS background-attachment

Categories

(Core Graveyard :: GFX, defect, P2)

Product:
Core Graveyard
Component:
GFX
Platform:
All
Other
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: dbaron, Assigned: beard)

References

(
URL
)

Details

(Keywords: css1, Whiteboard: 12008 should be rechecked once this is resolved.) 

It would be nice to support the CSS1 properties background-position and
background-attachment.  There seems to be some attempt at supporting background-
position, since it sometimes seems to cause a background that is tiled only in
one direction (using background-repeat) to run twice in that direction
(parallel) rather than once.  See the URL given for an example.  See tests
5.3.4, 5.3.6, and 5.3.7 (link above) for examples of these properties.‰
Status: NEW → ASSIGNED
Note that we do support some of background-position; currently only the pixel
values work, percentages and the enumerateds do not.
Summary: CSS background-position and background-attachment → CSS background-attachment
Background position is now working fully. So I changed the bug title...

Supporting background-attachment is currently waiting on a css2 spec
clarification.
I am curious what the spec clarification was that you were waiting for.  I had
assumed it was related to the relation between background-position and
background-attachment when background-attachment was fixed (on a non-BODY
element), but I now think that is actually well defined in the CSS2 spec (at
the end of the section on background-position).
Severity: enhancement → normal
In case the clarification required is what to do with fixed background
on non-BODY elements, here is how I understand the spec:

The image should be fixed relative to the viewport, but hidden except
the element is over the viewport, when the image "shines through" the
element. Thus in:

   http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/bgafixed.html

...the navy bar should be plain navy, except when it is in the middle of
the viewport, when you should be able to see the two cats in the navy box,
above the drawing of the other cat (Astrophy).

Right, David?
Basically, except the blue DIV should hide the first cat, so you should never
be able to see both cat images at once.

Here's my way of explaining it:

1) Position and tile the background as if it were a background on the viewport.
2) Clip whatever the result is at the edges of the element whose background it
 actually is.

This means:
1) A tiled background image that is fixed shouldn't move around when the
 document is scrolled.  The element whose background it is should "move over
 it."
2) A non-tiled background image should appear only when the (padding edge of
 the) element whose background it is is over that part of the viewport.
Ok, now what happens to the background when it is inside an element, say a DIV
with width & height properties and overflow: scroll? What about two DIVs that
scroll nested inside each other?
Nothing different.  The background is still fixed with respect to the viewport.

(Background fixing with respect to an arbitrary (scrolling) element is an
interesting idea.  I think this would best be handled by additional values on
background-attachment.  It is an interesting feature to think about, but it
isn't in the spec now.  Background fixing is wrt viewport.)
Setting all current Open/Normal to M4.
per leger, assigning QA contacts to all open bugs without QA contacts according
to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
Assignee: kipp → troy
Status: ASSIGNED → NEW
Since you've been working with michael to get all the basic features we need to
support this, and since you'll probably end up writing the code to make it work,
I'm giving the bug to you so you can enjoy closing it when finished :-)
QA Contact: 4144 → 4110
*** Bug 3963 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
*** Bug 3478 has been marked as a duplicate of this bug. ***
Target Milestone: M4 → M6
Target Milestone: M6 → M5
Per my conversation with Hakon:

> Okay, that's what we'll do then. Treat fixed background images as fixed with
> regard to the nearest scrolling container

Yes. I can't make any guaratees what solution the WG will settle on,
but I would be very surprised if it's different from yours.
Assignee: troy → beard
Status: ASSIGNED → NEW
Component: Layout → Compositor
Okay, layout has been changed and it works correctly except in one case. Fixing
that requires compositor changes.

The way fixed background attachment works is that layout sets the
NS_VIEW_PUBLIC_FLAG_DONT_BITBLT flag which tells the compositor that the view
should be repainted and not bitblt when moving or scrolling the view.

The nsScrollingView::Scroll() code has been changed to check the scrolled view's
flags and if that flag is set, then the view is repainted and not bitblt'd

The case that doesn't currently work is when there's a non-scrollable nested
element that has a fixed background attachment (see example below). What happens
in this case is that because the scrolled view can be bitblt'd we go ahead and
bitblt it. However, one of its child views can not be bitblt'd, and see we need
to make sure that it is repainted after doing the scroll.

Doing this efficiency (i.e., not walking each of the scrolled view's
child frames each time checking if any of them have this flag bit set) requires
compositor changes.

<HTML>
<BODY>
Some text
<DIV style="background-attacment: fixed; ...">
Some text in a DIV
</DIV>
</BODY>
</HTML>
Assignee: beard → michaelp
This also looks suspicously similar to bug #1045.
Assignee: michaelp → kmcclusk
which it is, anybody else confused by bugzilla sometimes? what bug is this?
Moving to M6.
Target Milestone: M5 → M6
Status: NEW → ASSIGNED
Target Milestone: M6 → M7
Summary: CSS background-attachment → {css1} CSS background-attachment
Assignee: kmcclusk → beard
Status: ASSIGNED → NEW
Patrick, This is a view/compositor bug so I am re-assigning back to you. Troy
describes the solution in his 4/24 message.
Status: NEW → ASSIGNED
Target Milestone: M7 → M8
moving to m9. beard's on vacation
Target Milestone: M9 → M11
*** Bug 12008 has been marked as a duplicate of this bug. ***
Target Milestone: M11 → M14
The test cases work as they should. Is this really a performance bug? I'll defer
performance for later.
Whiteboard: 12008 should be rechecked once this is resolved.
beard: I don't think this is a performance issue. Take a look at this page:
   http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/overflowscroll.html

Scroll it up and down. The white box in the middle explains the problem:
basically, we seem to be only repainting the inner element (overflow:scroll)
when the scrolling has finished, which leads to trails during the scroll.
Its difficult to explain; have a look.
Keywords: css1
Migrating from {css1} to css1 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...
Summary: {css1} CSS background-attachment → CSS background-attachment
Both test cases appear to work fine now in my 7-Feb-2000 build, using 
nsViewManager2. I should be able to close this bug when final migration is 
complete.

Fixed by nsViewManager2
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Keywords: verifyme
I'm verifying this and reopening a new bug. This bug has gotten unwieldy.
The new bug is bug 27841.
Status: RESOLVED → VERIFIED
Well... You knew what I meant, right? ;-)
Thanks David.
Keywords: verifyme
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.