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

RESOLVED FIXED

Status

Core Graveyard
GFX
P2
normal
RESOLVED FIXED
16 years ago
9 years ago

People

(Reporter: Brad Tiffany, Assigned: roc)

Tracking

(5 keywords)

Trunk
css2, helpwanted, qawanted, regression, testcase
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(5 attachments, 2 obsolete attachments)

(Reporter)

Description

16 years ago
The testcase in bug 46660 no longer displays properly in build 2001042608.

Updated

16 years ago
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

Comment 2

16 years ago
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.

Comment 4

16 years ago
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.

Updated

16 years ago
Target Milestone: --- → mozilla0.9.3

Comment 7

16 years ago
*** Bug 72788 has been marked as a duplicate of this bug. ***

Comment 8

16 years ago
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.  

Updated

16 years ago
Target Milestone: mozilla0.9.3 → mozilla0.9.4

Comment 9

16 years ago
*** Bug 93076 has been marked as a duplicate of this bug. ***

Updated

16 years ago
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?
Created attachment 52851 [details]
http://www.btinternet.com/~richard.shaw/testcase.htm
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.

Comment 17

16 years ago
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?

Comment 19

16 years ago
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 :-).

Comment 21

16 years ago
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?

Comment 23

16 years ago
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.  

Updated

16 years ago
Target Milestone: mozilla0.9.6 → mozilla0.9.7

Updated

16 years ago
Target Milestone: mozilla0.9.7 → mozilla1.0
Created attachment 59385 [details] [diff] [review]
Patch to quirk.css which adds body rule to create new stacking context

Updated

16 years ago
Target Milestone: mozilla1.0 → mozilla0.9.7

Updated

16 years ago
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. ***

Comment 36

15 years ago
*** Bug 148607 has been marked as a duplicate of this bug. ***

Comment 37

15 years ago
*** Bug 148607 has been marked as a duplicate of this bug. ***
Blocks: 148607
*** Bug 154585 has been marked as a duplicate of this bug. ***

Comment 39

15 years ago
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?

Comment 44

15 years ago
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.

Comment 46

15 years ago
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).

Comment 48

15 years ago
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.

Comment 51

15 years ago
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

15 years ago
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...

Comment 55

15 years ago
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

Updated

15 years ago
Whiteboard: branchOEM

Comment 59

15 years ago
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.
The patch is no good.

Updated

15 years ago
Keywords: nsbeta1+
Whiteboard: branchOEM → branchOEM, nsbeta1+
Target Milestone: Future → mozilla1.2beta

Comment 61

15 years ago
batch: adding topembed per Gecko2 document
http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html
Keywords: topembed

Updated

15 years ago
Keywords: branchOEM
Whiteboard: branchOEM, nsbeta1+
*** Bug 171433 has been marked as a duplicate of this bug. ***

Comment 63

15 years ago
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: topembed → topembed-

Updated

15 years ago
Blocks: 176349
*** Bug 183544 has been marked as a duplicate of this bug. ***

Comment 65

15 years ago
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. ***

Comment 67

15 years ago
*** Bug 186754 has been marked as a duplicate of this bug. ***
*** Bug 195828 has been marked as a duplicate of this bug. ***

Comment 69

14 years ago
Created attachment 130424 [details]
z-index and position problem in mozilla testcase

Comment 70

14 years ago
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. ***

Updated

14 years ago
Summary: [regression] Doesn't display position:absolute and z-index:-1 → Doesn't display position:absolute and z-index:-1
Target Milestone: mozilla1.2beta → ---

Comment 72

14 years ago
*** Bug 229159 has been marked as a duplicate of this bug. ***

Updated

14 years ago
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

Comment 74

14 years ago
*** Bug 231050 has been marked as a duplicate of this bug. ***
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 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)
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 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.

Updated

13 years ago
Blocks: 241589

Updated

13 years ago
No longer blocks: 241589
*** Bug 241736 has been marked as a duplicate of this bug. ***

Comment 82

13 years ago
*** Bug 241836 has been marked as a duplicate of this bug. ***

Comment 83

13 years ago
*** Bug 242663 has been marked as a duplicate of this bug. ***

Updated

13 years ago
Keywords: branchOEM, nsbeta1+, topembed- → css2, helpwanted

Updated

13 years ago
Attachment #59385 - Attachment is obsolete: true

Comment 84

13 years ago
(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

13 years ago
I believe the Hello Kitties have been replaced with our logos.

Comment 86

13 years ago
(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: 151375

Updated

13 years ago
Blocks: 204278

Comment 87

13 years ago
*** Bug 249870 has been marked as a duplicate of this bug. ***
*** Bug 254503 has been marked as a duplicate of this bug. ***

Comment 89

13 years ago
*** 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...

Comment 92

12 years ago
(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

12 years ago
*** 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. ***

Comment 96

12 years ago
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

12 years ago
(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

12 years ago
Created attachment 203622 [details]
new test case attached

Comment 99

12 years ago
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

Updated

12 years ago
Attachment #203622 - Attachment description: new sample page attached → new test case attached
Depends on: 317375
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
Last Resolved: 12 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 → ---
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.
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
Last Resolved: 12 years ago12 years ago
Resolution: --- → FIXED

Comment 107

11 years ago
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. ***

Updated

10 years ago
Duplicate of this bug: 393676

Comment 112

9 years ago
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.