Closed Bug 47742 Opened 24 years ago Closed 19 years ago

'Position:fixed' object with 'visibility:hidden' becomes visible briefly when it is moved.

Categories

(Core :: Web Painting, defect)

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

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: val, Assigned: roc)

References

Details

(Keywords: dom0, testcase)

Attachments

(1 file)

testcase from reporter's example
(deleted), text/html
Details 
From Bugzilla Helper:
User-Agent: Mozilla/4.6 [en-gb]C-CCK-MCD NetscapeOnline.co.uk  (Win98; I)
BuildID:    2000061311

An fixed position object, which is hidden and then moved using Javascript, 
becomes visible briefly in the position to which it has been moved.


Reproducible: Always
Steps to Reproduce:

The following code uses a position:fixed DIV:

<html>
<head>
<script>
function hideDiv(){
document.getElementById("divId").style.visibility="hidden";
document.getElementById("divId").style.top=0;
document.getElementById("divId").style.left=0;
}

function showDiv(){
document.getElementById("divId").style.top=200;
document.getElementById("divId").style.left=200;
document.getElementById("divId").style.visibility="visible";
}
</script>

</head>

<body bgcolor="#cccccc">

<div id="divId" style="position:fixed; top:100; left:100; height:50; width:200; 
visibility:hidden; background-color:#0000ff">
This is the DIV
</div>
<br><br><br><a href"#" onmouseover='showDiv()' onmouseout='hideDiv()'>mouseover 
here</a>

</body>
</html>



Actual Results:  

Although hidden first, the DIV flickers briefly in its new position
If the DIV is instead positioned absolutely or relatively, this does not happen.
							

Expected Results:  DIV should not be visible in its 'hidden' position.
Attached file testcase from reporter's example (deleted) — 

    
    

    
  
Confirmed on Linux 2000080308. Changing OS/Plat to All. Creating testcase from
user's example and adding keyword. 
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: testcase
OS: Windows 98 → All
Hardware: PC → All

    
    

    
  
Reassigning to Mark Attinasi, Mark, I had a brief discussion about this with
Nisheeth and we think the problem is that there's some timing related problem
between the frames and the views on this document that causes things to paint
incorrectly in this case, please have a look.
Assignee: jst → attinasi

    
    

    
  
This looks similar to another animation bug we had where setting clip and 
position at the same time was causing flashing. That one turned out to be a 
problem with synchronous painting and the message pump event priorities. that 
bug was fixed, but this one still flashes. I'll investigate further. Thanks for 
the testcase,  Tomer!
Status: NEW → ASSIGNED

    
    

    
  
Marking future because this is not critical to beta3/RTM. We'll get to it as 
soon as the Beta3+ priorities are completed. Others are encouraged to 
investigate and / or come up with potential fixes in the meantime.
Target Milestone: --- → Future
Keywords: dom0

    
    

    
  
Is bug 129844 related to this? In that bug position:fixed; is not used, but its
kind of the same result at this.
Assignee: attinasi → roc
Status: ASSIGNED → NEW
Component: DOM: Level 0 → Layout: View Rendering
Priority: P3 → --
QA Contact: desale → ian
Target Milestone: Future → ---
Depends on: 238493

    
    

    
  
I just tried running this under the debugger and placing a breakpoint in
RenderViews() to see who's calling it.  Nothing too interesting there -- it's
always called from the PAINT event widget sends.  What _is_ interesting is that
with the breakpoint placed in that function I see several calls to RenderViews()
when I hover the link.  Some of these are due to me moving off the link to the
debugger window, but what's interesting is that there is a point when we get
stopped at the breakpoint and _both_ rectangles (top left, and "where it should
be") are colored blue.  Furthermore, they both get painted blue in the same
RenderViews() pass.

roc, any idea what could cause that?

(For further reference, I have traced the code and verified that the style
reresolve posts the reflow PLEvent before the repaint PLEvent (the latter
because it uses DEFERRED). So we should be reflowing before we paint, and the
fact that the blue box is painted in the "right" place on the same pass
indicates that we are.  I also tried removing the FlushPendingUpdates() code we
have on mouse moves, but that didn't affect this, though it was my first guess
at the problem....)

    
    

    
  
Beats me. Maybe you should turn on display list dumping (the calls to
ShowDisplayList) and see what you get?

    
    

    
  
The output for a single hover on the link is (I only did the ShowDisplayList
under nsViewManager::RenderViews):

### display list length=1 ###
nsIView@0x83e8908{0,0,12278,8008 @ 0,0; p=(nil),m=0x83e88a0 z=0,zp=(nil)}
[x=2268, y=7728,
 w=9142, h=224, absX=0, absY=0]
VIEW_RENDERED 
### display list length=6 ###
nsIView@0x8789238{0,0,12250,6328 @ 0,0; p=(nil),m=0x87891d0 z=0,zp=(nil)} [x=0,
y=0, w=561
4, h=3514, absX=0, absY=0]
nsIView@0x865e7a0{0,0,12250,6328 @ 0,0; p=0x8789238,m=0x87891d0 z=0,zp=(nil)}
[x=0, y=0, w
=12250, h=6328, absX=0, absY=0]
PUSH_CLIP 
  nsIView@0x865e7a0{0,0,12250,6328 @ 0,0; p=0x8789238,m=0x87891d0 z=0,zp=(nil)}
[x=0, y=0,
 w=5614, h=3514, absX=0, absY=0]
  VIEW_ISTRANSPARENT 
  nsIView@0x87bb8f8{0,0,12250,6328 @ 0,0; p=0x865e7a0,m=0x87891d0 z=0,zp=(nil)}
[x=0, y=0,
 w=5614, h=3514, absX=0, absY=0]
  VIEW_RENDERED 
  nsIView@0x87c0c00{0,0,2800,700 @ 2800,2800; p=0x8789238,m=0x87891d0
z=0,zp=0x87c0c58} [x
=2800, y=2800, w=2800, h=700, absX=2800, absY=2800]
  VIEW_RENDERED 
  nsIView@0x865e7a0{0,0,12250,6328 @ 0,0; p=0x8789238,m=0x87891d0 z=0,zp=(nil)}
[x=0, y=0,
 w=12250, h=6328, absX=0, absY=0]
  POP_CLIP 
### display list length=6 ###
nsIView@0x8789238{0,0,12250,6328 @ 0,0; p=(nil),m=0x87891d0 z=0,zp=(nil)} [x=0,
y=0, w=280
0, h=700, absX=-2800, absY=-2800]
nsIView@0x865e7a0{0,0,12250,6328 @ 0,0; p=0x8789238,m=0x87891d0 z=0,zp=(nil)}
[x=-2800, y=
-2800, w=12250, h=6328, absX=-2800, absY=-2800]
PUSH_CLIP 
  nsIView@0x865e7a0{0,0,12250,6328 @ 0,0; p=0x8789238,m=0x87891d0 z=0,zp=(nil)}
[x=0, y=0,
 w=2800, h=700, absX=-2800, absY=-2800]
  VIEW_ISTRANSPARENT 
  nsIView@0x87bb8f8{0,0,12250,6328 @ 0,0; p=0x865e7a0,m=0x87891d0 z=0,zp=(nil)}
[x=0, y=0,
 w=2800, h=700, absX=-2800, absY=-2800]
  nsIView@0x87c0c00{0,0,2800,700 @ 2800,2800; p=0x8789238,m=0x87891d0
z=0,zp=0x87c0c58} [x
=0, y=0, w=2800, h=700, absX=0, absY=0]
  VIEW_RENDERED 
  nsIView@0x865e7a0{0,0,12250,6328 @ 0,0; p=0x8789238,m=0x87891d0 z=0,zp=(nil)}
[x=-2800, 
y=-2800, w=12250, h=6328, absX=-2800, absY=-2800]
  POP_CLIP 

In particular, the second and third list are identical except for a 2800 twip
offset (200px at my dpi, which is exactly the offset in the testcase).  That
seems to be the root of the problem -- we really are painting  this thing twice,
at two different locations, as far as I can tell.

    
    

    
  
Suppose that for some reason a platform paint event landed on the event queue
between style reresolution and the handling of the reflow PLEvent. It gets
handled with higher priority than the PLEvents. We repaint the whole window and
see that there is an element at location (0,0) and it is visible. We paint it.
Then the reflow PLEvent, the invalidate PLEvent and the platform paint event are
processed and we fix up the display. The fact that both boxes are visible at the
same time is perhaps just due to platform clipping to repaint just the dirty area.

Two questions: is this what's happening? I can look tomorrow. If so how can the
supposition in the first sentence happen assuming that we're the only app active? 

    
    

    
  
> Two questions: is this what's happening? 

Not that I can tell.  I put a printf in nsViewManager::RenderViews and another
in PresShell::ProcessReflowCommands (inside the |0 != mReflowCommands.Count()|
if).  When hovering and unhovering the link (from which I removed the href to
keep the window.status changes from muddling the waters), I consistently see the
presshell printf followed by two copies of the view manager printf.  I verified
that I do see the flicker as I do this...
Blocks: 264819
Depends on: 243726
Blocks: 225419
Blocks: 279415
No longer blocks: 264819

    
    

    
  
I think this is WFM in my debug build that has the "frame display lists" patch in it (bug 317375).
Depends on: 317375

    
    

    
  
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060126 Firefox/1.6a1 ID:2006012614

WFM
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
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: