[CSS] Fixed attribute ignores z-index.




15 years ago
9 months ago


(Reporter: wuffxiii, Assigned: roc)


Windows XP
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)





15 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040830 Voidbuffalo/0.9.3 (Firefox/0.9.3 [nightlies] polymorph)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040830 Voidbuffalo/0.9.3 (Firefox/0.9.3 [nightlies] polymorph)

There is a more detailed explanation and deliberation here:


The pages detailing this issue can be found here:


The issue is that using fixed in a 'background:' CSS element will cause the
header to always show above a span popup regardless of the z-index.  As 'fixed'
is the only way to stop images scrolling, this is a hinderance and I think that
perhaps this shouldn't be the correct functionality of fixed and that it should
obey the z-index.  If a header has a 'background: url(image.png) 0 0 fixed;'
element with 'z-index: 50' set and a hover popup element has a 'z-index: 100;'
element, the popup should show above the header, shouldn't it?

This isn't the case, as the examples detail.  I did discuss this on mozillaZine
but I had no definite answers, there were suggestions but they all heralded the
same issue -- as long as 'fixed' is used, 'z-index' will be ignored.

Reproducible: Always
Steps to Reproduce:
[1] Create a CSS based page which has a class or a header with a fixed
background element and set it with a low z-index (such as 0 or 50).
[2] Add a popup hover element and give it the highest possible z-index (100).
Actual Results:  
Unless the fixed attribute is removed, the popup will always show below the
class/header regardless of whatever z-index attributes are set in either or any
case.  Only removing the fixed attribute will allow the popup to show above the
class/header but then the image will scroll with the site and can't remain fixed.

Expected Results:  
The purpose of fixed is to hold an element in place (X,Y) and the purpose of
z-index is to set the Z position of the element, is it not?  If that is the case
then the fixed attribute is negating the functionality of z-index.  Thusly,
fixed should only have a z-index of 100 unless a z-index is provided, in which
case that z-index should be obeyed instead of the default.


15 years ago
Assignee: firefox → nobody
Component: General → Layout
Product: Firefox → Browser
QA Contact: firefox.general → core.layout
Version: unspecified → 1.7 Branch
This looks like a manifestation of bug 191830, but I'm a little confused by the
fact that the positioned div ends up too low too... That _does_ have a view,
after all, and being positioned should be painted above the fixed-background thing.

Seeing this on trunk too (with 1.8a3 on Win98).
Assignee: nobody → roc
Component: Layout → Layout: View Rendering
Depends on: 191830
Ever confirmed: true
QA Contact: core.layout → ian
Version: 1.7 Branch → Trunk
Yeah, looks like a real bug. I should fix this.
Priority: -- → P2

Comment 3

14 years ago
This bug also manifests on http://beesbuzz.biz/blog/ with the sidebar (a floated element).  I recall this happening in 1.0 when no z-index was specified (even though that shouldn't have been necessary, and strictly-speaking floated elements aren't supposed to honor z-index to begin with); now in 1.5 either the bug is different or the z-index workaround has stopped working (I don't know if the bug was ever actually fixed in 1.0).
Fixed by the patch in bug 317375.

*** This bug has been marked as a duplicate of 317375 ***
Last Resolved: 14 years ago
Depends on: 317375
Resolution: --- → DUPLICATE
I shouldn't have marked this as a duplicate. It should just depend on 317375.
Resolution: DUPLICATE → ---
The url is gone, so there is no way to check if this has been fixed by bug 317375.
Reporter, could you please put the url back online?

Comment 7

14 years ago
A test is available at http://beesbuzz.biz/blog/?style=bugtest - if the bug is fixed, then the right sidebar will be visible, and the various boxes will appear to be transparent and sliding over the fixed plaid background.
In that case, it is fixed :)
Last Resolved: 14 years ago14 years ago
Resolution: --- → FIXED

Comment 9

14 years ago

When can we expect to see this making it into the mainline binary release?  I'd like to turn the transparent backgrounds back on entirely but am sick of people IMing, emailing, and posting comments about how my layout is broken in Firefox.
Please attach a testcase to this bug so that in the future testing can happen using that testcase?  This bug will still need to be verified.

> When can we expect to see this making it into the mainline binary release? 

In about a year, hopefully.
Component: Layout: View Rendering → Layout: Web Painting
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.