Closed
Bug 219444
Opened 21 years ago
Closed 20 years ago
Setting zIndex with Javascript for an absolute positioned table doesn't work.
Categories
(Core :: Web Painting, defect)
Core
Web Painting
Tracking
()
RESOLVED
FIXED
People
(Reporter: rosen, Assigned: roc)
References
Details
(Keywords: testcase)
Attachments
(2 files)
|
768 bytes,
text/html
|
Details | |
|
6.78 KB,
patch
|
bzbarsky
:
review+
bzbarsky
:
superreview+
|
Details | Diff | Splinter Review |
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•21 years ago
|
||
|
||
Comment 2•21 years ago
|
||
Confirmed on Win98 as well, with a 1.5b build.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: PC → All
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
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
|
Assignee | |
Comment 5•20 years ago
|
||
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.
|
|
||
Comment 6•20 years ago
|
||
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.
|
|
Assignee | |
Comment 7•20 years ago
|
||
Attachment #172307 -
Flags: superreview?(bzbarsky)
Attachment #172307 -
Flags: review?(bzbarsky)
|
|
||
Comment 8•20 years ago
|
||
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+
|
|
Assignee | |
Comment 9•20 years ago
|
||
> 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.
|
|
Assignee | |
Comment 10•20 years ago
|
||
fixed
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
|
|
||
Comment 11•20 years ago
|
||
Oh, right. I forgot that we change aMinChange within the function.
|
||
Updated•6 years ago
|
Component: Layout: View Rendering → Layout: Web Painting
You need to log in
before you can comment on or make changes to this bug.
Description
•