Closed
Bug 78087
Opened 24 years ago
Closed 19 years ago
Doesn't display position:(absolute, relative, fixed) with negative z-index
Categories
(Core Graveyard :: GFX, defect, P2)
Core Graveyard
GFX
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: btiffany, Assigned: roc)
References
Details
(5 keywords)
Attachments
(5 files, 2 obsolete files)
(deleted),
text/html
|
Details | |
(deleted),
patch
|
dbaron
:
review-
dbaron
:
superreview-
|
Details | Diff | Splinter Review |
(deleted),
text/html
|
Details | |
(deleted),
text/html
|
Details | |
(deleted),
patch
|
dbaron
:
review+
dbaron
:
superreview+
|
Details | Diff | Splinter Review |
The testcase in bug 46660 no longer displays properly in build 2001042608.
Updated•24 years ago
|
Keywords: regression,
testcase
Comment 1•24 years ago
|
||
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•24 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.
Comment 3•24 years ago
|
||
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•24 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.
Comment 5•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
Target Milestone: --- → mozilla0.9.3
Comment 8•23 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•23 years ago
|
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Updated•23 years ago
|
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Assignee | ||
Comment 11•23 years ago
|
||
The testcase is inaccessible. Can someone attach a testcase to this bug?
Comment 12•23 years ago
|
||
Assignee | ||
Comment 13•23 years ago
|
||
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?
Assignee | ||
Comment 14•23 years ago
|
||
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.
Assignee | ||
Comment 15•23 years ago
|
||
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•23 years ago
|
||
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•23 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'
Assignee | ||
Comment 18•23 years ago
|
||
Does the code that I suggested cause problems in other browsers?
Comment 19•23 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.
Assignee | ||
Comment 20•23 years ago
|
||
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•23 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.
Assignee | ||
Comment 22•23 years ago
|
||
I say we resolve this as INVALID. Any objections?
Comment 23•23 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•23 years ago
|
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Updated•23 years ago
|
Target Milestone: mozilla0.9.7 → mozilla1.0
Comment 24•23 years ago
|
||
Updated•23 years ago
|
Target Milestone: mozilla1.0 → mozilla0.9.7
Updated•23 years ago
|
Target Milestone: mozilla0.9.7 → mozilla1.0.1
Assignee | ||
Comment 25•23 years ago
|
||
You probably want to run this by the page-load tests... If they check out, then
sr=roc+moz
Comment 26•23 years ago
|
||
*** Bug 114996 has been marked as a duplicate of this bug. ***
Comment 27•23 years ago
|
||
*** Bug 116021 has been marked as a duplicate of this bug. ***
Comment 28•23 years ago
|
||
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•23 years ago
|
||
*** Bug 116725 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 30•23 years ago
|
||
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•23 years ago
|
||
*** Bug 119722 has been marked as a duplicate of this bug. ***
Comment 32•23 years ago
|
||
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
Comment 33•23 years ago
|
||
*** Bug 132719 has been marked as a duplicate of this bug. ***
Comment 34•23 years ago
|
||
*** Bug 138050 has been marked as a duplicate of this bug. ***
Comment 35•23 years ago
|
||
*** Bug 139530 has been marked as a duplicate of this bug. ***
Comment 36•23 years ago
|
||
*** Bug 148607 has been marked as a duplicate of this bug. ***
Comment 37•23 years ago
|
||
*** Bug 148607 has been marked as a duplicate of this bug. ***
Comment 38•22 years ago
|
||
*** Bug 154585 has been marked as a duplicate of this bug. ***
Comment 39•22 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.
Comment 40•22 years ago
|
||
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
Comment 41•22 years ago
|
||
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.
Assignee | ||
Comment 42•22 years ago
|
||
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•22 years ago
|
||
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•22 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.
Comment 45•22 years ago
|
||
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•22 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.
Comment 47•22 years ago
|
||
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•22 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.
Comment 49•22 years ago
|
||
> 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....
Assignee | ||
Comment 50•22 years ago
|
||
I think we should check in the patch (assuming it doesn't hurt page load times).
It's quirks mode only.
Comment 51•22 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•22 years ago
|
||
I think at least commercial build of mozilla should include the patch for quirk
mode.
Assignee | ||
Comment 53•22 years ago
|
||
jrgm, can you run page-load-time tests for this quirks mode patch? Or tell us
who can?
dbaron, any objections?
Comment 54•22 years ago
|
||
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•22 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>
Comment 56•22 years ago
|
||
John has a point... the <body> has a nonzero margin and we should not be making
it a containing block for abs pos content.
Assignee | ||
Comment 57•22 years ago
|
||
Ah yes. Something evil is required.
Assignee | ||
Comment 58•22 years ago
|
||
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•22 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.
Assignee | ||
Comment 60•22 years ago
|
||
The patch is no good.
Updated•22 years ago
|
Keywords: nsbeta1+
Whiteboard: branchOEM → branchOEM, nsbeta1+
Target Milestone: Future → mozilla1.2beta
Comment 61•22 years ago
|
||
batch: adding topembed per Gecko2 document
http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html
Keywords: topembed
Comment 62•22 years ago
|
||
*** Bug 171433 has been marked as a duplicate of this bug. ***
Comment 63•22 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+.
Comment 64•22 years ago
|
||
*** Bug 183544 has been marked as a duplicate of this bug. ***
Comment 65•22 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
Comment 66•22 years ago
|
||
*** Bug 184154 has been marked as a duplicate of this bug. ***
Comment 67•22 years ago
|
||
*** Bug 186754 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 68•22 years ago
|
||
*** Bug 195828 has been marked as a duplicate of this bug. ***
Comment 69•21 years ago
|
||
Comment 70•21 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
Comment 71•21 years ago
|
||
*** Bug 220831 has been marked as a duplicate of this bug. ***
Updated•21 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•21 years ago
|
||
*** Bug 229159 has been marked as a duplicate of this bug. ***
Updated•21 years ago
|
Summary: Doesn't display position:absolute and z-index:-1 → Doesn't display position:(absolute, relative, fixed) with negative z-index
Assignee | ||
Comment 73•21 years ago
|
||
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•21 years ago
|
||
*** Bug 231050 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 75•21 years ago
|
||
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.
Assignee | ||
Comment 76•21 years ago
|
||
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)
Assignee | ||
Comment 77•21 years ago
|
||
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•21 years ago
|
||
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-
Assignee | ||
Comment 79•21 years ago
|
||
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...
Assignee | ||
Comment 80•21 years ago
|
||
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.
Assignee | ||
Comment 81•21 years ago
|
||
*** Bug 241736 has been marked as a duplicate of this bug. ***
Comment 82•21 years ago
|
||
*** Bug 241836 has been marked as a duplicate of this bug. ***
Comment 83•21 years ago
|
||
*** Bug 242663 has been marked as a duplicate of this bug. ***
Updated•21 years ago
|
Updated•21 years ago
|
Attachment #59385 -
Attachment is obsolete: true
Comment 84•20 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•20 years ago
|
||
I believe the Hello Kitties have been replaced with our logos.
Comment 86•20 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.
Comment 87•20 years ago
|
||
*** Bug 249870 has been marked as a duplicate of this bug. ***
Comment 88•20 years ago
|
||
*** Bug 254503 has been marked as a duplicate of this bug. ***
Comment 89•20 years ago
|
||
*** Bug 265130 has been marked as a duplicate of this bug. ***
Comment 90•20 years ago
|
||
*** Bug 272257 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 91•20 years ago
|
||
Need to work on this...
Comment 92•20 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•20 years ago
|
||
*** Bug 289393 has been marked as a duplicate of this bug. ***
Comment 94•19 years ago
|
||
*** Bug 308639 has been marked as a duplicate of this bug. ***
Comment 95•19 years ago
|
||
*** Bug 311248 has been marked as a duplicate of this bug. ***
Comment 96•19 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•19 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•19 years ago
|
||
Comment 99•19 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•19 years ago
|
Attachment #203622 -
Attachment description: new sample page attached → new test case attached
Comment 100•19 years ago
|
||
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•19 years ago
|
||
Marking RESOLVED FIXED as per comment 100
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Comment 102•19 years ago
|
||
(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•19 years ago
|
||
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
Updated•19 years ago
|
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 104•19 years ago
|
||
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 105•19 years ago
|
||
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+
Assignee | ||
Comment 106•19 years ago
|
||
checked in
Status: REOPENED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → FIXED
Comment 107•18 years ago
|
||
Is there any chance to have the fix backported to Firefox 2.0?
Comment 108•18 years ago
|
||
(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•18 years ago
|
||
*** Bug 355445 has been marked as a duplicate of this bug. ***
Comment 110•18 years ago
|
||
*** Bug 360388 has been marked as a duplicate of this bug. ***
Comment 112•17 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
Updated•16 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•