Last Comment Bug 78087 - Doesn't display position:(absolute, relative, fixed) with negative z-index
: Doesn't display position:(absolute, relative, fixed) with negative z-index
Status: RESOLVED FIXED
: css2, helpwanted, qawanted, regression, testcase
Product: Core Graveyard
Classification: Graveyard
Component: GFX (show other bugs)
: Trunk
: All All
: P2 normal with 13 votes (vote)
: ---
Assigned To: Robert O'Callahan (:roc) (email my personal email if necessary)
: Hixie (not reading bugmail)
Mentors:
: 93076 114996 116021 116725 119722 132719 139530 154585 171433 183544 184154 195828 220831 229159 231050 241736 241836 242663 249870 254503 265130 272257 289393 308639 311248 355445 360388 393676 (view as bug list)
Depends on: 317375
Blocks: 148607 151375 grouper 204278
  Show dependency treegraph
 
Reported: 2001-04-28 23:04 PDT by Brad Tiffany
Modified: 2009-01-25 10:28 PST (History)
65 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
http://www.btinternet.com/~richard.shaw/testcase.htm (152 bytes, text/html)
2001-10-09 19:21 PDT, David Baron :dbaron: ⌚️UTC-7 (busy September 14-25)
no flags Details
Patch to quirk.css which adds body rule to create new stacking context (609 bytes, patch)
2001-11-27 13:40 PST, Kevin McCluskey (gone)
no flags Details | Diff | Splinter Review
z-index and position problem in mozilla testcase (500 bytes, text/html)
2003-08-26 11:59 PDT, CoL
no flags Details
fix (27.65 KB, patch)
2004-03-06 15:53 PST, Robert O'Callahan (:roc) (email my personal email if necessary)
dbaron: review-
dbaron: superreview-
Details | Diff | Splinter Review
testcase (1.15 KB, text/html)
2004-03-06 16:11 PST, Robert O'Callahan (:roc) (email my personal email if necessary)
no flags Details
new test case attached (308 bytes, text/html)
2005-11-18 22:26 PST, Derek Versteegen
no flags Details
fix (3.63 KB, patch)
2006-01-26 20:01 PST, Robert O'Callahan (:roc) (email my personal email if necessary)
dbaron: review+
dbaron: superreview+
Details | Diff | Splinter Review

Description Brad Tiffany 2001-04-28 23:04:32 PDT
The testcase in bug 46660 no longer displays properly in build 2001042608.
Comment 1 Boris Zbarsky [:bz] (TPAC) 2001-04-30 19:52:39 PDT
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....
Comment 2 Arthur Lewis 2001-05-27 02:50:25 PDT
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.
Comment 3 Boris Zbarsky [:bz] (TPAC) 2001-05-28 12:51:44 PDT
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.
Comment 4 Arthur Lewis 2001-05-28 21:41:19 PDT
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.
Comment 5 Boris Zbarsky [:bz] (TPAC) 2001-05-29 08:00:36 PDT
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.
Comment 6 Hixie (not reading bugmail) 2001-05-29 23:35:57 PDT
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.
Comment 7 Lasse Marøen 2001-07-14 12:56:07 PDT
*** Bug 72788 has been marked as a duplicate of this bug. ***
Comment 8 Joshua Prowse 2001-07-15 06:26:19 PDT
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.  
Comment 9 Mats Palmgren (:mats) 2001-08-01 19:45:37 PDT
*** Bug 93076 has been marked as a duplicate of this bug. ***
Comment 10 Kevin McCluskey (gone) 2001-10-04 12:26:27 PDT
Moving to Mozilla0.9.6
Comment 11 Robert O'Callahan (:roc) (email my personal email if necessary) 2001-10-09 17:20:19 PDT
The testcase is inaccessible. Can someone attach a testcase to this bug?
Comment 12 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2001-10-09 19:21:25 PDT
Created attachment 52851 [details]
http://www.btinternet.com/~richard.shaw/testcase.htm
Comment 13 Robert O'Callahan (:roc) (email my personal email if necessary) 2001-10-10 05:54:17 PDT
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?
Comment 14 Robert O'Callahan (:roc) (email my personal email if necessary) 2001-10-10 06:03:59 PDT
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.
Comment 15 Robert O'Callahan (:roc) (email my personal email if necessary) 2001-10-10 06:08:57 PDT
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.
Comment 16 Boris Zbarsky [:bz] (TPAC) 2001-10-10 09:26:35 PDT
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.
Comment 17 Joshua Prowse 2001-10-10 10:51:24 PDT
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'
Comment 18 Robert O'Callahan (:roc) (email my personal email if necessary) 2001-10-10 10:54:17 PDT
Does the code that I suggested cause problems in other browsers?
Comment 19 Joshua Prowse 2001-10-10 13:10:03 PDT
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.  
Comment 20 Robert O'Callahan (:roc) (email my personal email if necessary) 2001-10-10 14:35:10 PDT
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 :-).
Comment 21 Joshua Prowse 2001-10-11 12:55:35 PDT
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.  
Comment 22 Robert O'Callahan (:roc) (email my personal email if necessary) 2001-10-22 19:11:38 PDT
I say we resolve this as INVALID. Any objections?
Comment 23 Joshua Prowse 2001-10-23 13:30:22 PDT
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.  
Comment 24 Kevin McCluskey (gone) 2001-11-27 13:40:03 PST
Created attachment 59385 [details] [diff] [review]
Patch to quirk.css which adds body rule to create new stacking context
Comment 25 Robert O'Callahan (:roc) (email my personal email if necessary) 2001-11-27 14:11:28 PST
You probably want to run this by the page-load tests... If they check out, then

sr=roc+moz
Comment 26 Mats Palmgren (:mats) 2001-12-13 17:22:07 PST
*** Bug 114996 has been marked as a duplicate of this bug. ***
Comment 27 Boris Zbarsky [:bz] (TPAC) 2001-12-19 11:33:46 PST
*** Bug 116021 has been marked as a duplicate of this bug. ***
Comment 28 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2001-12-23 18:40:17 PST
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?
Comment 29 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2001-12-23 18:40:25 PST
*** Bug 116725 has been marked as a duplicate of this bug. ***
Comment 30 Robert O'Callahan (:roc) (email my personal email if necessary) 2001-12-23 20:53:38 PST
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.
Comment 31 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2002-01-12 21:13:01 PST
*** Bug 119722 has been marked as a duplicate of this bug. ***
Comment 32 Kevin McCluskey (gone) 2002-02-22 07:22:40 PST
Bulk moving Mozilla1.01 bugs to future-P1. I will pull from the future-P1 list
to schedule bugs for post Mozilla1.0 milestones
Comment 33 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2002-03-21 20:54:44 PST
*** Bug 132719 has been marked as a duplicate of this bug. ***
Comment 34 Mats Palmgren (:mats) 2002-04-17 16:43:11 PDT
*** Bug 138050 has been marked as a duplicate of this bug. ***
Comment 35 Boris Zbarsky [:bz] (TPAC) 2002-04-23 12:28:06 PDT
*** Bug 139530 has been marked as a duplicate of this bug. ***
Comment 36 Jacek Piskozub 2002-06-02 05:41:55 PDT
*** Bug 148607 has been marked as a duplicate of this bug. ***
Comment 37 Jacek Piskozub 2002-06-02 13:43:02 PDT
*** Bug 148607 has been marked as a duplicate of this bug. ***
Comment 38 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2002-06-27 11:01:56 PDT
*** Bug 154585 has been marked as a duplicate of this bug. ***
Comment 39 Erik Arvidsson 2002-07-12 08:25:56 PDT
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.
Comment 40 Boris Zbarsky [:bz] (TPAC) 2002-07-12 13:05:52 PDT
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?
Comment 41 Eric A. Meyer (dead account) 2002-07-12 13:37:02 PDT
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.
Comment 42 Robert O'Callahan (:roc) (email my personal email if necessary) 2002-07-12 19:13:30 PDT
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!).
Comment 43 Hixie (not reading bugmail) 2002-07-12 20:43:35 PDT
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?
Comment 44 Erik Arvidsson 2002-07-13 08:00:56 PDT
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.
Comment 45 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2002-07-15 13:44:35 PDT
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.
Comment 46 Joseph Reagle 2002-07-15 13:54:00 PDT
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. 
Comment 47 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2002-07-15 14:41:00 PDT
I'm on the CSS working group, and I'm planning to bring it up (within a more
general discussion of z-index issues).
Comment 48 Jerry 2002-07-22 19:13:01 PDT
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.

Comment 49 Boris Zbarsky [:bz] (TPAC) 2002-07-22 19:19:22 PDT
> 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....
Comment 50 Robert O'Callahan (:roc) (email my personal email if necessary) 2002-07-23 08:34:27 PDT
I think we should check in the patch (assuming it doesn't hurt page load times).
It's quirks mode only.
Comment 51 Joshua Prowse 2002-07-23 10:19:17 PDT
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.  
Comment 52 Jerry 2002-07-23 19:43:31 PDT
I think at least commercial build of mozilla should include the patch for quirk
mode.
Comment 53 Robert O'Callahan (:roc) (email my personal email if necessary) 2002-07-23 20:33:28 PDT
jrgm, can you run page-load-time tests for this quirks mode patch? Or tell us
who can?

dbaron, any objections?
Comment 54 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2002-07-23 21:01:09 PDT
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...
Comment 55 John Morrison 2002-07-23 21:41:34 PDT
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>
Comment 56 Boris Zbarsky [:bz] (TPAC) 2002-07-23 23:07:38 PDT
John has a point... the <body> has a nonzero margin and we should not be making
it a containing block for abs pos content.
Comment 57 Robert O'Callahan (:roc) (email my personal email if necessary) 2002-07-24 06:36:54 PDT
Ah yes. Something evil is required.
Comment 58 Robert O'Callahan (:roc) (email my personal email if necessary) 2002-07-24 06:44:22 PDT
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
Comment 59 Jerry 2002-08-09 06:03:35 PDT
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.
Comment 60 Robert O'Callahan (:roc) (email my personal email if necessary) 2002-08-09 12:17:52 PDT
The patch is no good.
Comment 61 Marek Z. Jeziorek 2002-09-13 09:49:56 PDT
batch: adding topembed per Gecko2 document
http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html
Comment 62 Mats Palmgren (:mats) 2002-09-28 14:49:11 PDT
*** Bug 171433 has been marked as a duplicate of this bug. ***
Comment 63 Jaime Rodriguez, Jr. 2002-10-07 16:16:34 PDT
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+.
Comment 64 Boris Zbarsky [:bz] (TPAC) 2002-12-04 14:07:08 PST
*** Bug 183544 has been marked as a duplicate of this bug. ***
Comment 65 Scott D Friedemann 2002-12-04 14:21:50 PST
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
Comment 66 Boris Zbarsky [:bz] (TPAC) 2002-12-07 16:09:28 PST
*** Bug 184154 has been marked as a duplicate of this bug. ***
Comment 67 Olivier Cahagne 2002-12-25 10:26:49 PST
*** Bug 186754 has been marked as a duplicate of this bug. ***
Comment 68 Robert O'Callahan (:roc) (email my personal email if necessary) 2003-03-03 19:53:41 PST
*** Bug 195828 has been marked as a duplicate of this bug. ***
Comment 69 CoL 2003-08-26 11:59:24 PDT
Created attachment 130424 [details]
z-index and position problem in mozilla testcase
Comment 70 CoL 2003-08-26 12:07:53 PDT
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
Comment 71 Mats Palmgren (:mats) 2003-09-30 13:46:17 PDT
*** Bug 220831 has been marked as a duplicate of this bug. ***
Comment 72 Malcolm Rowe 2003-12-22 04:20:02 PST
*** Bug 229159 has been marked as a duplicate of this bug. ***
Comment 73 Robert O'Callahan (:roc) (email my personal email if necessary) 2004-01-16 07:17:03 PST
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.
Comment 74 Jesiah S 2004-02-09 11:43:52 PST
*** Bug 231050 has been marked as a duplicate of this bug. ***
Comment 75 Robert O'Callahan (:roc) (email my personal email if necessary) 2004-03-06 15:53:32 PST
Created attachment 143146 [details] [diff] [review]
fix

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 76 Robert O'Callahan (:roc) (email my personal email if necessary) 2004-03-06 16:10:21 PST
Comment on attachment 143146 [details] [diff] [review]
fix

You asked for this a couple of milestones ago IIRC ... better late than never
:-)
Comment 77 Robert O'Callahan (:roc) (email my personal email if necessary) 2004-03-06 16:11:41 PST
Created attachment 143148 [details]
testcase

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 78 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2004-03-08 12:25:31 PST
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
Comment 79 Robert O'Callahan (:roc) (email my personal email if necessary) 2004-03-08 12:42:54 PST
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...
Comment 80 Robert O'Callahan (:roc) (email my personal email if necessary) 2004-03-08 21:43:07 PST
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.
Comment 81 Robert O'Callahan (:roc) (email my personal email if necessary) 2004-04-26 07:56:16 PDT
*** Bug 241736 has been marked as a duplicate of this bug. ***
Comment 82 HARUNAGA Hirotoshi 2004-04-26 23:04:08 PDT
*** Bug 241836 has been marked as a duplicate of this bug. ***
Comment 83 Anne (:annevk) 2004-05-05 04:32:38 PDT
*** Bug 242663 has been marked as a duplicate of this bug. ***
Comment 84 Mayo Jordanov 2004-06-21 18:32:02 PDT
(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). 
Comment 85 Jacek Piskozub 2004-06-21 21:56:09 PDT
I believe the Hello Kitties have been replaced with our logos.
Comment 86 Mayo Jordanov 2004-06-22 11:35:00 PDT
(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.
Comment 87 Bill Mason 2004-07-05 10:03:51 PDT
*** Bug 249870 has been marked as a duplicate of this bug. ***
Comment 88 Boris Zbarsky [:bz] (TPAC) 2004-08-05 16:55:37 PDT
*** Bug 254503 has been marked as a duplicate of this bug. ***
Comment 89 Bill Mason 2004-10-19 13:00:31 PDT
*** Bug 265130 has been marked as a duplicate of this bug. ***
Comment 90 Mats Palmgren (:mats) 2004-11-29 19:51:31 PST
*** Bug 272257 has been marked as a duplicate of this bug. ***
Comment 91 Robert O'Callahan (:roc) (email my personal email if necessary) 2005-03-21 18:47:09 PST
Need to work on this...
Comment 92 Jail 2005-03-22 01:53:30 PST
(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
Comment 93 José Jeria 2005-04-07 02:51:39 PDT
*** Bug 289393 has been marked as a duplicate of this bug. ***
Comment 94 Dave Townsend [:mossop] 2005-09-15 03:22:28 PDT
*** Bug 308639 has been marked as a duplicate of this bug. ***
Comment 95 Peter van der Woude [:Peter6] 2005-10-05 14:13:09 PDT
*** Bug 311248 has been marked as a duplicate of this bug. ***
Comment 96 Francisco León 2005-10-06 05:08:00 PDT
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?
Comment 97 Hermann Schwab 2005-10-06 05:39:12 PDT
(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'
Comment 98 Derek Versteegen 2005-11-18 22:26:41 PST
Created attachment 203622 [details]
new test case attached
Comment 99 Derek Versteegen 2005-11-18 22:29:27 PST
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
Comment 100 Peter van der Woude [:Peter6] 2006-01-26 15:58:26 PST
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
Comment 101 Steve England [:stevee] 2006-01-26 17:16:51 PST
Marking RESOLVED FIXED as per comment 100
Comment 102 philippe (part-time) 2006-01-26 19:26:31 PST
(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 103 Bill Gianopoulos [:WG9s] 2006-01-26 19:28:36 PST
Comment on attachment 130424 [details]
z-index and position problem in mozilla testcase

image file for this testcase no longer exists
Comment 104 Robert O'Callahan (:roc) (email my personal email if necessary) 2006-01-26 20:01:42 PST
Created attachment 209794 [details] [diff] [review]
fix

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.
Comment 105 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2006-01-26 20:21:01 PST
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.
Comment 106 Robert O'Callahan (:roc) (email my personal email if necessary) 2006-02-05 12:52:40 PST
checked in
Comment 107 Giuseppe Bilotta 2006-08-20 04:56:33 PDT
Is there any chance to have the fix backported to Firefox 2.0?
Comment 108 Bill Gianopoulos [:WG9s] 2006-08-20 05:53:03 PDT
(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.
Comment 109 Phil Ringnalda (:philor) 2006-10-04 16:12:00 PDT
*** Bug 355445 has been marked as a duplicate of this bug. ***
Comment 110 Dave Townsend [:mossop] 2006-11-11 12:54:11 PST
*** Bug 360388 has been marked as a duplicate of this bug. ***
Comment 111 Mats Palmgren (:mats) 2007-08-25 09:47:30 PDT
*** Bug 393676 has been marked as a duplicate of this bug. ***
Comment 112 Steven Rowat 2008-03-13 10:27:19 PDT
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

Note You need to log in before you can comment on or make changes to this bug.