1045 - CSS background-attachment

Status: VERIFIED FIXED

(Core Graveyard :: GFX, defect, P2)

Description

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

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.‰

Comment 1

[kipp]

Note that we do support some of background-position; currently only the pixel
values work, percentages and the enumerateds do not.

Comment 2

[kipp]

Background position is now working fully. So I changed the bug title...

Supporting background-attachment is currently waiting on a css2 spec
clarification.

Comment 3

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

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).

Comment 4

[Hixie (not reading bugmail)]

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?

Comment 5

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

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.

Comment 6

[Peter Linss]

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?

Comment 7

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

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.)

Comment 8

[leger]

Setting all current Open/Normal to M4.

Comment 9

[Paul MacQuiddy]

per leger, assigning QA contacts to all open bugs without QA contacts according
to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

Comment 10

[kipp]

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 :-)

Comment 11

[troy]

*** Bug 3963 has been marked as a duplicate of this bug. ***

Comment 12

[troy]

*** Bug 3478 has been marked as a duplicate of this bug. ***

Comment 13

[troy]

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.

Comment 14

[troy]

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>

Comment 15

[Patrick C. Beard]

This also looks suspicously similar to bug #1045.

Comment 16

[Patrick C. Beard]

which it is, anybody else confused by bugzilla sometimes? what bug is this?

Comment 17

[karnaze (gone)]

Moving to M6.

Comment 18

[Kevin McCluskey (gone)]

Patrick, This is a view/compositor bug so I am re-assigning back to you. Troy
describes the solution in his 4/24 message.

Comment 19

[chris hofmann]

moving to m9. beard's on vacation

Comment 20

[troy]

*** Bug 12008 has been marked as a duplicate of this bug. ***

Comment 21

[Patrick C. Beard]

The test cases work as they should. Is this really a performance bug? I'll defer
performance for later.

Comment 22

[Hixie (not reading bugmail)]

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.

Comment 23

[Hixie (not reading bugmail)]

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...

Comment 24

[Patrick C. Beard]

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.

Comment 25

[Patrick C. Beard]

Fixed by nsViewManager2

Comment 26

[Hixie (not reading bugmail)]

I'm verifying this and reopening a new bug. This bug has gotten unwieldy.
The new bug is bug 27841.

Comment 27

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

No, it's bug 28741. :-)

Comment 28

[Hixie (not reading bugmail)]

Well... You knew what I meant, right? ;-)
Thanks David.