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: http://forums.mozillazine.org/viewtopic.php?p=755872 The pages detailing this issue can be found here: http://mastaile.mine.nu/Popup/BGFixed http://mastaile.mine.nu/Popup/BGNotFixed 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:  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).  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.
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
Status: UNCONFIRMED → NEW
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
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 ***
Status: NEW → RESOLVED
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.
Status: RESOLVED → REOPENED
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?
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 :)
Status: REOPENED → RESOLVED
Last Resolved: 14 years ago → 14 years ago
Resolution: --- → FIXED
Hooray! 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.