Closed Bug 78087 Opened 23 years ago Closed 19 years ago

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

Categories

(Core Graveyard :: GFX, defect, P2)

Product:
Core Graveyard
Component:
GFX
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: btiffany, Assigned: roc)

References

Details

(5 keywords)

Attachments

(5 files, 2 obsolete files)

http://www.btinternet.com/~richard.shaw/testcase.htm
152 bytes, text/html
Details
fix
27.65 KB, patch
dbaron
: review-
dbaron
: superreview-
Details | Diff | Splinter Review
testcase
1.15 KB, text/html
Details
new test case attached
308 bytes, text/html
Details
fix
3.63 KB, patch
dbaron
: review+
dbaron
: superreview+
Details | Diff | Splinter Review 
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
batch: adding topembed per Gecko2 document
http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html
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: topembed → topembed-
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. ***

    
    

    
  
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
        — 
          — 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
        — 
      

    


  
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
        — 
      

    


  

    
    

    
  
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
        — 
          — 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 ago → 19 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

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: