Closed Bug 78087 Opened 24 years ago Closed 19 years ago

Doesn't display position:(absolute, relative, fixed) with negative z-index

Categories

(Core Graveyard :: GFX, defect, P2)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: btiffany, Assigned: roc)

References

Details

(5 keywords)

Attachments

(5 files, 2 obsolete files)

The testcase in bug 46660 no longer displays properly in build 2001042608.
Keywords: regression, testcase
The problem is that z-index:-1 puts that div below the <body> and for some reason the <body> is not being transparent even though no background is set. I see this on linux build 2001-04-30-08. Over to compositor....
Assignee: pierre → kmcclusk
Status: UNCONFIRMED → NEW
Component: Style System → Compositor
Ever confirmed: true
OS: Mac System 8.6 → All
QA Contact: ian → petersen
Hardware: Macintosh → All
As in the simple test case at http://208.36.69.72:81/zindexTest.html, Any positioned content with z-index at any negative value that should be visible is not.
The testcase at http://208.36.69.72:81/zindexTest.html looks invalid. Giving a div z-index:-1 will put it below its parent (in this case the body). Since the body does not have a transparent background, the div becomes invisible.
Pardon my ignorance, but should the body be included in z-Index for purposes of display and visibility? Both IE and Opera display this page (and the page I'm developing for a client that caused me to notice this behavior) as expected. Having something actually hidden by, say, the body's background image, would seem odd behavior.
Yes, the <body> element's z-index is 0 by default and it _should_ be included for purposes of display. The CSS spec does not differentiate between <body> and any other element in this matter. IE and Opera get it wrong. ccing hixie for confirmation.
Actually that last point is debatable. The <body> element has a 'z-index' of 'auto' which in this particular case means it can be assumed to have a z index of 0, however since the background is propagated back to the canvas, technically it is transparent and thus things "below" it should display... cc'ing dbaron because I'm not very confident that what I said makes sense.
Target Milestone: --- → mozilla0.9.3
*** Bug 72788 has been marked as a duplicate of this bug. ***
IF the Opera and Internet Explorer implementations are incorrect, AND negative z-index values are supposed to be obscured by a background, THEN what is the solution to the problem for coders? I know nothing about Mozilla. I was designing a web page and I came across this problem. I found this report and assumed that this behaviour was a bug.
Target Milestone: mozilla0.9.3 → mozilla0.9.4
*** Bug 93076 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Moving to Mozilla0.9.6
Target Milestone: mozilla0.9.5 → mozilla0.9.6
The testcase is inaccessible. Can someone attach a testcase to this bug?
We DO clear out the background style on <body> when we propagate its background to the canvas, so that's not the issue. I think what's happening is that <body> has "z-index: auto" by default, which means that there is just one stacking context for the entire document. The background on the canvas is at z-index 0 within that stacking context. Therefore anything with negative z-index is displayed behind the background. I suspect that the reason IE and Opera do it differently is because they don't implement "z-index: auto" correctly, treating it as zero instead. I guess it's arguable that the canvas background should always be displayed behind everything regardless of the z-index of the other stuff. If that's the case then Layout needs to set the z-index of the child of the viewport view to zero. Maybe we can do this with just a style rule?
OK. More spec-lawyering. The CSS2 Rec does say that the root element establishes a stacking context. But it also says "The background of the box generated by the root element covers the entire canvas." So, I conclude that although we implement this by hoisting the background style out to the canvas (which is the parent of the root element in our implementation), the background really does belong to the root element. Therefore if the root element is to be treated consistently with the other elements, boxes at negative z-index within the root element's stacking context should be drawn behind the root element's (i.e., canvas') background. So what we do is correct.
The solution to the problem for Web coders is to establish a new stacking context below the root element. Everything in that context will be displayed above the root element's background. So this should work, in Mozilla at least: <html style="background: ..."> <body style="z-index: 0; position: relative; top: 0; left: 0;"> <div style="z-index: -1;">...</div> ... </body></html>If implementing z-index correctly is going to cause a lot of compatibility problems, then maybe in quirks mode we should treat "z-index: auto" as 0.
we could just put: body { position: relative; top: 0; left: 0; z-index: 0; } in quirk.css if we want... That may make sense for the quirks case.
Implementing this correctly is going to cause a lot of compatibility issues since, apparently, no other major browser does implement this correctly. As a web author whose only interest in the Mozilla project is to make sure that my pages display correctly in the browser, I would very much apprecaite that this be treated as a 'quirk'
Does the code that I suggested cause problems in other browsers?
Robert O'Callahan, from my informal testing, implementing this correctly causes no compatibility issues in other browsers. I'm sorry if my previous message was unclear, I was only expressing my support for including body {position: relative;top: 0;left: 0;z-index: 0;} in the quirks.css file. I think that would be a grand solution that would resolve the issue for all involved. It is the expected behaviour. Let's do it.
Whatever we end up doing with quirks.css, I suggest that you add that <body> style wherever you need to, since it makes the pages (more) standards compliant which should give you a warm fuzzy feeling :-).
I'll be sure to make my code standards compliant. Now that I know how to do it. What's the process for editing the quirks.css file and having it picked up in the nightlies/milestones, etc. If I knew how to do it, I would submit it. It's something that's so very easy that one of the old hats should probably take care of this and knock another bug off Mozilla's burgeoning lists.
I say we resolve this as INVALID. Any objections?
I'm not a Mozilla.org regular, but I think that it would be a good idea to edit quirks.css as was suggested. Otherwise, I now know what to do with my code, so I'd be okay. However, if quirks.css isn't edited than Mozilla will have a different behaviour than pretty much every browser out there (Opera, IE, etc.) and people (like me) will think it's a bug. If I knew how to go about submitting a modification to quirks.css, I'd do it. Since I don't know how to do that, I'll leave this in your hands. I've said my piece.
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Target Milestone: mozilla0.9.7 → mozilla1.0
Target Milestone: mozilla1.0 → mozilla0.9.7
Target Milestone: mozilla0.9.7 → mozilla1.0.1
You probably want to run this by the page-load tests... If they check out, then sr=roc+moz
*** Bug 114996 has been marked as a duplicate of this bug. ***
*** Bug 116021 has been marked as a duplicate of this bug. ***
Hmm -- perhaps this is our bug -- since the body background or the background on the root element is supposed to be propagated to the canvas? Or not?
*** Bug 116725 has been marked as a duplicate of this bug. ***
See my comment #14 above. I'm convinced that we are correctly following the CSS2 Rec and IE and Opera are not. If you want the quirks fix for this, then r= the patch and make sure Kevin checks it in.
*** Bug 119722 has been marked as a duplicate of this bug. ***
Bulk moving Mozilla1.01 bugs to future-P1. I will pull from the future-P1 list to schedule bugs for post Mozilla1.0 milestones
Priority: -- → P1
Target Milestone: mozilla1.0.1 → Future
*** Bug 132719 has been marked as a duplicate of this bug. ***
*** Bug 138050 has been marked as a duplicate of this bug. ***
*** Bug 139530 has been marked as a duplicate of this bug. ***
*** Bug 148607 has been marked as a duplicate of this bug. ***
*** Bug 148607 has been marked as a duplicate of this bug. ***
Blocks: 148607
*** Bug 154585 has been marked as a duplicate of this bug. ***
1. This is a bug. IE and Opera are doing the right thing. 2. Backgrounds got nothing to do with it. Now I'll try to motivate why this is a bug. The following text can be found in 9.9 in CSS2 rec "Each box belongs to one stacking context." "A local stacking context is atomic; boxes in other stacking contexts may not come between any of its boxes. " Take the following code: <style type="text/css"> div { position: absolute; left: 100px; top: 100px; font-size: 100px; } </style> <div id="d-1" style="z-index: 0; background-color: #eeeeee; width: 200px; height: 200px;"> <div id="d-2" style="z-index: -1; color: red;">-1</div> <div id="d-3" style="z-index: 0; color: blue;">0</div> <div id="d-4" style="z-index: 1; color: green;">1</div> </div> The d-1 element creates a local stacking context. d-2, d-3 and d-4 are in the same stacking context. d-1 is not in the same stacking context as d-2, d-3 or d-3. But in Mozilla d-1 comes between d-2 and d-3 and therefore the spec is not followed. The correct behavior is to first paint d-1, then d-2, d-3 and d-4. This behavior is followed by IE and Opera and since the parent element (which creates the local stacking context) cannot come between any of its children the background will be painted behind all the children.
Well, now. This is interesting. Section 9.9, paragraph 2: "Each box belongs to one stacking context." Section 9.9, paragraph 3: "A local stacking context is atomic; boxes in other stacking contexts may not come between any of its boxes." Section 9.9, paragraph 4: "An element that establishes a local stacking context generates a box that has two stack levels: one for the stacking context it creates (always '0') and one for the stacking context to which it belongs (given by the 'z-index' property)." So. paragraph 4 seems to flat-out contradict paragraph 2, unless we say that the box establishing the stacking context has a stack level in the stacking context but does not "belong to the stacking context", whatever that may mean. Also, can a box have a stack level in a stacking context but not be "in" it for purposes of the atomicity constraint? If so, what does it having a stack level even mean? Ian? David?
Keywords: qawanted
QA Contact: petersen → ian
I'm neither Ian nor David, but I'll weigh in with my opinion. I've always understood the positioning rules to mean that when you have an element that establishes a stacking context, it is part of the context it establishes. All of its descendants are z-stacked in relation to the establishing element, which sits at '0' on the local context's z-axis. However, all of those elements (the establisher and its descendants) are like a little atomic group that sits in a larger stacking context. That's how it was described in Chapter 9 of "CSS: The Definitive Guide" (p.338). So in Erik's example (comment 39), I would argue that 'd-1' does in fact stack along with its descendants, and they should be in the order (from back to front): d-2 d-1 d-3 d-4 ...because if two elements have the same 'z-index' value, the later one in the source gets painted "on top." (I think.) I would also feel that, if other browsers don't act this way, they're incorrect to do so.
Obviously I agree with Eric Meyer, since that's what I implemented. I think the intent of the spec is completely clear. The only possible reason for defining the stacking level of a box in the stacking context it creates to be zero, is so that negative-z-index children will appear behind it. Also, I believe this is wrong: > This behavior is followed by IE and Opera Have you tried your example in IE? I haven't checked recently, but I thought IE rendered negative z-index elements behind the parent (except for the root element!).
The example in comment 39 should render in the following order, ignoring all layers that are absent in this example (such as borders, background images, text-decoration and the like): d-2 foreground d-1 background (background comes before foreground because of 9.5) d-1 foreground d-3 foreground (document tree order as per 9.9) d-4 foreground Note that the value of the z-index of the d-1 element is irrelevant, as it is the root element it always creates a stacking context, and regardless of the value of the z-index property, it is always at level 0 with respect to the other elements in the stacking context it forms. Plus everything Eric said. Does that answer the question?
I'm not convinced that Mozilla is doing the right thing, but on the other hand I'm no longer convinced that Mozilla is doing the wrong thing. I'll just leave it be until I can come up with something that strengthens the claims in either direction.
I agree with comment 41, comment 42, and comment 43, in saying that our behavior is correct in general. However, I still think that what I said in comment 28 (and roc debated in comment 13) could be a reasonable argument for saying that our behavior is incorrect in the specific case of backgrounds that are propagated to the canvase (those on the root element and on BODY). In particular, see the definition of canvas: http://www.w3.org/TR/REC-CSS2/intro.html#canvas . 9.9 says that "the root element creates a /root stacking context/". This might suggest that our behavior is incorrect. Note that: * 10.1 says that the root element is inside the initial containing block * 9.1.1 suggests that the initial containing block is inside the canvas However, this would only be relevant if the background propagated from the root element or from BODY were drawn on the canvas. Reading 14.2 closely suggests that this is not the case: "The background of the box generated by the root element covers the entire canvas." This seems to me to be a statement that the area covered is different, but that it is still drawn on the same object. In other words, I agree with comment 14 that our behavior is correct according to the current CSS2 spec. However, in cases where existing implementations differ from the spec and pages on the web have come to depend on those implementations, the working group might be willing to consider errata to the spec (or, more likely, changes in a future version of the spec) that would bring the spec into line with existing practice.
Given the spec is ambigous, why don't you guys write to the authors/comment list and ask for clarification and an erratum! Clearly the spec is failing to provide for interoperable implementation.
I'm on the CSS working group, and I'm planning to bring it up (within a more general discussion of z-index issues).
Since css2 spec doesnot say z-index can not be -1 clearly, and there are over 10 duplicate bugs( it suggests that many site are using this syntax). I think before CSS2 spec change its defination and syntax of z-index, maybe we should check in the patch.
> Since css2 spec doesnot say z-index can not be -1 clearly, Of course it does not say it clearly. It does not say it at all. It can't since z-index _can_ be -1. I'm not sure how this is related to your suggestion that we check in the patch....
I think we should check in the patch (assuming it doesn't hurt page load times). It's quirks mode only.
There is no consensus on how this should be handled: A demo file with negative z-index: http://n-sider.com/test/negz.html Screenshots: Opera 6: http://n-sider.com/test/negz-opera.PNG IE5 Mac: http://n-sider.com/test/negz-msiem.PNG IE6 Win: http://n-sider.com/test/negz-msiew.PNG Mozilla: http://n-sider.com/test/negz-moz.PNG Therefore, it makes sense for Mozilla to have two behaviors. One that mimics IE6 in quirks mode (since most people expect things to work that way) and then another behavior that conforms to the W3C specifications in standards mode. It does not makes sense to leave the current behavior in quirks mode because of the sheer number of people having trouble with this. If the quirks behavior is not changed, then some evangelism should ensue: possibly an example page that shows how to get standardized code that conforms to the W3C and works on multiple platforms.
I think at least commercial build of mozilla should include the patch for quirk mode.
jrgm, can you run page-load-time tests for this quirks mode patch? Or tell us who can? dbaron, any objections?
Well, sort of. The WG will be discussing this soon. Basically as soon as I write up a message to start that discussion (which I've been actioned to do), in fact...
Sure, I can run those tests. However, (not to drag out the discussion but...), is that patch correct? Specifically, with that rule in quirks.css, this absolutely positioned div is no longer flush with the top left corner of the viewport. Instead, it is offset down and right by what I assume is m/b/p. <html><body><div style="position: absolute; background-color: #ff6600; top: 0; left: 0; ">This text 'top:0; left:0;'</div></body></html>
John has a point... the <body> has a nonzero margin and we should not be making it a containing block for abs pos content.
Ah yes. Something evil is required.
z-index only applies to positioned elements but we want to apply it to BODY without positioning BODY. On the other hand, it looks like we don't actually enforce that, so we just have to give BODY a view. hmmm
Whiteboard: branchOEM
what's status of this bug? Is the patch good enough or need another patch? If the patch is good, I want to apply it to OEM branch at least. There are several dups of this bug when access sun internal websites.
Keywords: nsbeta1+
Whiteboard: branchOEM → branchOEM, nsbeta1+
Target Milestone: Future → mozilla1.2beta
Keywords: topembed
Keywords: branchOEM
Whiteboard: branchOEM, nsbeta1+
*** Bug 171433 has been marked as a duplicate of this bug. ***
Topembed- as this is not currently blocking a major embedding customer. Should you disagree, pls renominate, by removing the minus from topembed, and provide reasons you believe this should be topembed+.
Keywords: topembedtopembed-
Blocks: grouper
*** Bug 183544 has been marked as a duplicate of this bug. ***
Since I'm being CC:ed, here are a couple pages that don't show any z-index stuff in Mozilla. http://www.expertune.com/products.html http://www.expertune.com/literature.html
*** Bug 184154 has been marked as a duplicate of this bug. ***
*** Bug 186754 has been marked as a duplicate of this bug. ***
*** Bug 195828 has been marked as a duplicate of this bug. ***
Attached file z-index and position problem in mozilla testcase (obsolete) (deleted) —
I created a testcase, it works fine under IE, Opera, but still not in Mozilla :( Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030718
*** Bug 220831 has been marked as a duplicate of this bug. ***
Summary: [regression] Doesn't display position:absolute and z-index:-1 → Doesn't display position:absolute and z-index:-1
Target Milestone: mozilla1.2beta → ---
*** Bug 229159 has been marked as a duplicate of this bug. ***
Summary: Doesn't display position:absolute and z-index:-1 → Doesn't display position:(absolute, relative, fixed) with negative z-index
Taking. This needs to be fixed now because CSS2.1 has changed things so that backgrounds of elements that are stacking contexts are behind all children, even those with negative z-index.
Assignee: kmcclusk → roc
Priority: P1 → P2
*** Bug 231050 has been marked as a duplicate of this bug. ***
Attached patch fix (deleted) — Splinter Review
Okay, here it is! The basic idea is quite logical: views that induce stacking contexts and have children generate two display list elements: one for the background and one for the foreground. To make this work we have to refine nsIViewObserver to we can paint and dispatch events to individual layers. That's basically all it takes. I saved some work by ripping out some useless Paint indirection through nsView. Note that the clipping being done by nsScrollPortView was actually redundant; nsViewManager already does that clipping on its behalf using PUSH_CLIP and POP_CLIP display list elements.
Comment on attachment 143146 [details] [diff] [review] fix You asked for this a couple of milestones ago IIRC ... better late than never :-)
Attachment #143146 - Flags: superreview?(dbaron)
Attachment #143146 - Flags: review?(dbaron)
Attached file testcase (deleted) —
This testcase shows the problem and resolution quite clearly. One thing that this shows is that by targeting events at layers we've got some amount of event transparency. You can click on the -1 z-index text when it's between Hello Kitties.
Comment on attachment 143146 [details] [diff] [review] fix >+ if (aPaintFlags & NS_VIEW_PAINT_BACKGROUND) { > rv = frame->Paint(mPresContext, aRenderingContext, aDirtyRect, > NS_FRAME_PAINT_LAYER_BACKGROUND); >+ } >+ if (aPaintFlags & NS_VIEW_PAINT_FOREGROUND) { > rv = frame->Paint(mPresContext, aRenderingContext, aDirtyRect, > NS_FRAME_PAINT_LAYER_FLOATS); > rv = frame->Paint(mPresContext, aRenderingContext, aDirtyRect, > NS_FRAME_PAINT_LAYER_FOREGROUND); >- >+ } This is the wrong idea. These frame->Paint() calls propagate all the way down the tree (except through floats) -- whereas for this you want to separate the background of the frame itself from everything in its descendants (see CSS2.1 E.2 or 9.9.1). The solution might be something like: * expose nsFrame::PaintSelf (perhaps by making it virtual or wrapping it with a virtual function -- since tables and a few other things might need something different -- and there might be some frames that don't use it) * call PaintSelf with an additional parameter from the code above (defaulted to false for everything else) * make nsFrame::PaintSelf bail out if that additional parameter is false and the frame establishes a new stacking context
Attachment #143146 - Flags: superreview?(dbaron)
Attachment #143146 - Flags: superreview-
Attachment #143146 - Flags: review?(dbaron)
Attachment #143146 - Flags: review-
Ah, oops. Right, sure, that should be fairly straightforward, but > * make nsFrame::PaintSelf bail out if that additional parameter is false and > the frame establishes a new stacking context It should bail out if the parameter is false and the frame has a view. The PaintSelf call from nsIPresShell::Paint will be called to paint the background for *all* frames with views. I should be able to turn this around tonight...
Ah well. This is going to require refactoring of the ::Paint methods for several frames, to separate frame background/border/outline painting from the rest of their painting. I guess this will have to wait for 1.8.
Blocks: 241589
No longer blocks: 241589
*** Bug 241736 has been marked as a duplicate of this bug. ***
*** Bug 241836 has been marked as a duplicate of this bug. ***
*** Bug 242663 has been marked as a duplicate of this bug. ***
Attachment #59385 - Attachment is obsolete: true
(In reply to comment #77) > One thing that this shows is that by targeting events at layers we've got some > amount of event transparency. You can click on the -1 z-index text when it's > between Hello Kitties. I'm not sure if this was fixed and broken again, but you can't click on the Hello Kitties, as it will not be rendered (at least not on Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7b) Gecko/ 20040421 or Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a1) Gecko/20040520).
I believe the Hello Kitties have been replaced with our logos.
(In reply to comment #85) > I believe the Hello Kitties have been replaced with our logos. The hello kitties is there, as well as the logos. My bad. The thing that is missing is the table with cyan background and the "This text is zindex minus 1", but the test case implies it should be visible.
Blocks: 204278
*** Bug 249870 has been marked as a duplicate of this bug. ***
*** Bug 254503 has been marked as a duplicate of this bug. ***
*** Bug 265130 has been marked as a duplicate of this bug. ***
*** Bug 272257 has been marked as a duplicate of this bug. ***
Need to work on this...
(In reply to comment #91) > Need to work on this... That'd be excellent!!! Just yesterday I had to jump through hoops with an already complex css layout because of this bug, it's done now for that site but there'll be others... - Abhi
*** Bug 289393 has been marked as a duplicate of this bug. ***
*** Bug 308639 has been marked as a duplicate of this bug. ***
*** Bug 311248 has been marked as a duplicate of this bug. ***
Just commenting with some info of my duped bug: http://www.w3schools.com/css/tryit.asp?filename=trycss_zindex2 has a simple testcase for this, and it works on firefox. If i copy the code and save it locally and downloading the lightbulb image, it doesn't work. Why does it work there? Is it because it is listed inside a textarea that is also inside a table?
(In reply to comment #96) > Just commenting with some info of my duped bug 311248: > > http://www.w3schools.com/css/tryit.asp?filename=trycss_zindex2 It also works in DOM-Inspector, maybe because it is in an iframe. It doesn't work if you open the frame in a separate tab, neither in the tab nor in DOMI: Right-click, This Frame, 'Show only this frame' or 'Open Frame in New Window' or 'Open Frame in New Tab'
Attached file new test case attached (deleted) —
Comment on attachment 203622 [details] new test case attached views fine in the edit screen here in bugzilla, but when loaded in the parent window it disappears: http://www.zolaweb.com/z-index_test.htm
Attachment #203622 - Attachment description: z-index does not appear when it is a negative value → new sample page attached
Attachment #203622 - Attachment description: new sample page attached → new test case attached
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060126 Firefox/1.6a1 ID:2006012614 WFM after bug 317375 landed
Marking RESOLVED FIXED as per comment 100
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
(In reply to comment #101) > Marking RESOLVED FIXED as per comment 100 > This is *not* fixed in Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060126 Firefox/1.6a1 ID:2006012604 The cyan coloured block with the text 'This text is zindex minus 1' in attachment https://bugzilla.mozilla.org/attachment.cgi?id=143148 is not displayed.
Comment on attachment 130424 [details] z-index and position problem in mozilla testcase image file for this testcase no longer exists
Attachment #130424 - Attachment is obsolete: true
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Attached patch fix (deleted) — Splinter Review
Indeed, there was a remaining issue for viewport backgrounds. This fixes it by ensuring the canvas BorderBackground display items are propagated to the BorderBackground list for the viewport itself.
Attachment #209794 - Flags: superreview?(dbaron)
Attachment #209794 - Flags: review?(dbaron)
Comment on attachment 209794 [details] [diff] [review] fix r+sr=dbaron, although a slightly more verbose comment (perhaps mention negative z-index) might be nice.
Attachment #209794 - Flags: superreview?(dbaron)
Attachment #209794 - Flags: superreview+
Attachment #209794 - Flags: review?(dbaron)
Attachment #209794 - Flags: review+
checked in
Status: REOPENED → RESOLVED
Closed: 19 years ago19 years ago
Resolution: --- → FIXED
Is there any chance to have the fix backported to Firefox 2.0?
(In reply to comment #107) > Is there any chance to have the fix backported to Firefox 2.0? > The short answer is no. The reason for this is that this rather simple looking patch is dependent on a much larger fix detailed in bug 317375, which redesigned the way a lot of this area of code worked. In fact the code that this simple fix patches does not even exist on the branch because it is code that was added by the fix for bug 317375. The code added for that bug is way too complex to be adding this late in the Firefox 2.0 cycle and also sparked numerous regression bugs, 12 of which are still outstanding as I write this. Sorry, but you will have to wait for Firefox 3.0 for this fix.
*** Bug 355445 has been marked as a duplicate of this bug. ***
*** Bug 360388 has been marked as a duplicate of this bug. ***
Hi, I was hit by this bug in FF 2.0.0.12 Mac PPC, found my way here, read the above thread, understood most but not all of it (in my defence, the W3C pages about stacking order have to be one of the most obscure explanations in existence; clearly many people differ about what they 'really mean'), and then: --> I tried the quick fix: set <body> to {position: relative; z-index: 0}. And Lo! IT WORKS! Behaves like Safari now. My two questions: 1. Can I expect that this (seemingly no-downside) solution will also work in other FF versions and OSs? So I can just continue and use negative z-indexes, as long as I set body to relative and body z-index to 0? 2. If so, why can't this be done behind-the-scenes inside FF 2, since apparently FF defaulting the body z-index to "auto" is what causes the problem? I'm not a code-writer, so I assume I just don't understand deep enough to see why not. But I'm curious. Even if there is a semantic problem (arising from ambiguities in the CSS spec), which has to be worked into a deeper level in the relation to the canvas, still having it set to z-0 would be superior until FF 3 is released? Or is there a downside to setting it to 0 that isn't immediately apparent? Steven
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: