Closed
Bug 1045
Opened 26 years ago
Closed 25 years ago
CSS background-attachment
Categories
(Core Graveyard :: GFX, defect, P2)
Tracking
(Not tracked)
VERIFIED
FIXED
M14
People
(Reporter: dbaron, Assigned: beard)
References
()
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.‰
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.
Reporter | ||
Comment 3•26 years ago
|
||
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•26 years ago
|
||
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?
Reporter | ||
Comment 5•26 years ago
|
||
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•26 years ago
|
||
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?
Reporter | ||
Comment 7•26 years ago
|
||
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 9•26 years ago
|
||
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•26 years ago
|
||
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 :-)
Updated•26 years ago
|
QA Contact: 4144 → 4110
Comment 11•26 years ago
|
||
*** Bug 3963 has been marked as a duplicate of this bug. ***
Comment 12•26 years ago
|
||
*** Bug 3478 has been marked as a duplicate of this bug. ***
Comment 13•26 years ago
|
||
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
Comment 14•26 years ago
|
||
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 | ||
Updated•26 years ago
|
Assignee: beard → michaelp
Assignee | ||
Comment 15•26 years ago
|
||
This also looks suspicously similar to bug #1045.
Assignee | ||
Updated•26 years ago
|
Assignee: michaelp → kmcclusk
Assignee | ||
Comment 16•26 years ago
|
||
which it is, anybody else confused by bugzilla sometimes? what bug is this?
Updated•26 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M6 → M7
Updated•26 years ago
|
Summary: CSS background-attachment → {css1} CSS background-attachment
Updated•26 years ago
|
Assignee: kmcclusk → beard
Status: ASSIGNED → NEW
Comment 18•26 years ago
|
||
Patrick, This is a view/compositor bug so I am re-assigning back to you. Troy
describes the solution in his 4/24 message.
Assignee | ||
Updated•26 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Updated•26 years ago
|
Target Milestone: M7 → M8
Comment 19•26 years ago
|
||
moving to m9. beard's on vacation
Assignee | ||
Updated•26 years ago
|
Target Milestone: M9 → M11
Comment 20•25 years ago
|
||
*** Bug 12008 has been marked as a duplicate of this bug. ***
Assignee | ||
Updated•25 years ago
|
Target Milestone: M11 → M14
Assignee | ||
Comment 21•25 years ago
|
||
The test cases work as they should. Is this really a performance bug? I'll defer
performance for later.
Updated•25 years ago
|
Whiteboard: 12008 should be rechecked once this is resolved.
Comment 22•25 years ago
|
||
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•25 years ago
|
||
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...
Updated•25 years ago
|
Summary: {css1} CSS background-attachment → CSS background-attachment
Assignee | ||
Comment 24•25 years ago
|
||
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.
Assignee | ||
Comment 25•25 years ago
|
||
Fixed by nsViewManager2
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Comment 26•25 years ago
|
||
I'm verifying this and reopening a new bug. This bug has gotten unwieldy.
The new bug is bug 27841.
Status: RESOLVED → VERIFIED
Reporter | ||
Comment 27•25 years ago
|
||
No, it's bug 28741. :-)
Comment 28•25 years ago
|
||
Well... You knew what I meant, right? ;-)
Thanks David.
Updated•16 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•