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)

Product:
Core
Component:
Web Painting
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: rosen, Assigned: roc)

References

Details

(Keywords: testcase)

Attachments

(2 files)

Reporters testcase
768 bytes, text/html
Details
fix
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.
Attached file Reporters testcase — 

    
  
Keywords: testcase

    
    

    
  
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

    
    

    
  
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.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        fix
        — 
          — Splinter Review
      

    


  

        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
Closed: 20 years ago
Resolution: --- → FIXED

    
    

    
  
Oh, right.  I forgot that we change aMinChange within the function.
Blocks: 253781
Component: Layout: View Rendering → Layout: Web Painting

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: