Setting zIndex with Javascript for an absolute positioned table doesn't work.

RESOLVED FIXED

Status

()

Core
Layout: View Rendering
RESOLVED FIXED
15 years ago
14 years ago

People

(Reporter: rosen, Assigned: roc)

Tracking

({testcase})

Trunk
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.4) Gecko/20030624

I have two tables with position:absolute and the same z-index 10 set per css.
The second table is correctly drawn above the first. In a Javascript-function I
change the zIndex of table1 to 20. Now table1 should be above table2. This does
not happen.

Reproducible: Always

Steps to Reproduce:
open this page:

<html>
<head>
<title>test</title>
<style type="text/css">
.bla {
	position:absolute;
	border-color:red;
	border-width:2px;
	border-style:solid;
	background-color:yellow;
	z-index:10;
}
#t1 {
	left:5px;
	top:5px;
}
#t2 {
	left:30px;
	top:30px;
}
</style>
<script>
function test() {
	document.getElementById("t1").style.zIndex=20;
}
</script>
</head>
<body bgcolor="white" onLoad="test()">

<table class="bla" id="t1">
<tr><td>11111111111</td></tr>
<tr><td>11111111111</td></tr>
<tr><td>11111111111</td></tr>
<tr><td>11111111111</td></tr>
</table>

<table class="bla" id="t2">
<tr><td>22222222222</td></tr>
<tr><td>22222222222</td></tr>
<tr><td>22222222222</td></tr>
<tr><td>22222222222</td></tr>
</table>

</body>
</html>

Actual Results:  
table t2 is above table t1.


Expected Results:  
table t1 should be above table t2.

Comment 1

15 years ago
Created attachment 131592 [details]
Reporters testcase

Updated

15 years ago
Keywords: testcase
Confirmed on Win98 as well, with a 1.5b build.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: PC → All

Comment 3

14 years ago
please FIX this bug, its open since 93 and my page relies on this. There is NO
WORKAROUND this bug, so its important.

Joe Robe

Comment 4

14 years ago
Seems like NO ONE takes care of this ! I am developing a web application with
the look and feel of an windows application . Works AWESOME, but I have to lock
out all my users of Mozilla and force them to use IE due to this MAJOR BUG !!

If no one takes care, I would like to be assigned to it so it gets finally fixed.

Joe
The problem is that when we do ReResolveStyleContext on the table-outer-frame,
CalcStyleDifference returns 0 in CaptureChange, because 'compare' is 0 (the old
and new style contexts have the same rule node). We do have two different style
contexts, though. I don't understand enough about the style system to know why
the rule nodes are the same or what should be done about it. Boris probably knows.
The basic problem, I bet, has to do with the relationship between the inner and
outer frame...  The inner frame is a child of the outer, but the style context
of the outer is a child of that of the _inner_.

Now when we do this style context reresolution game, we essentially assume that
if a parent has a certain hint we don't need to bother with that hint for child
frames.  That's why we assign the return value of CaptureChange to aMinChange. 
The optimization in CalcStyleDifference is the same idea -- since our rulenode
didn't change, the styles applying to us did not change, so the only things that
will change about us are things we inherit.  But if we inherit them, then they
must have changed on some ancestor and that ancestor will deal with it.

In this case, we end up with a sync hint for the inner table frame and no hint
at all for the outer frame, since this code assumes that the inner frame (which
is the parent in the style context tree) will handle things.

So we can either hack ReResolveStyleContext to know about this special
relationship (like we hack out the reflow hint when reresolving out-of-flows) or
we can change the ApplyRenderingChangeToTree code to handle this situation.
Created attachment 172307 [details] [diff] [review]
fix
Attachment #172307 - Flags: superreview?(bzbarsky)
Attachment #172307 - Flags: review?(bzbarsky)
Comment on attachment 172307 [details] [diff] [review]
fix

>Index: layout/base/nsFrameManager.cpp

>+              nsChangeHint aAssumeChange)

Maybe "aChangeToAssume"?

>+  return aMinChange;

Want to file a followup bug on making this return something useful?
Attachment #172307 - Flags: superreview?(bzbarsky)
Attachment #172307 - Flags: superreview+
Attachment #172307 - Flags: review?(bzbarsky)
Attachment #172307 - Flags: review+
> Maybe "aChangeToAssume"?

OK

> Want to file a followup bug on making this return something useful?

It is useful, isn't it? It's the change we applied (or predicted will apply by
frame inheritance) to the frame.
fixed
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
Oh, right.  I forgot that we change aMinChange within the function.
You need to log in before you can comment on or make changes to this bug.