Closed Bug 47742 Opened 21 years ago Closed 15 years ago

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


(Core :: Web Painting, defect)

Not set





(Reporter: val, Assigned: roc)



(Keywords: dom0, testcase)


(1 file)

From Bugzilla Helper:
User-Agent: Mozilla/4.6 [en-gb]C-CCK-MCD  (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:

function hideDiv(){

function showDiv(){


<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
<br><br><br><a href"#" onmouseover='showDiv()' onmouseout='hideDiv()'>mouseover 


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.
Confirmed on Linux 2000080308. Changing OS/Plat to All. Creating testcase from
user's example and adding keyword. 
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!
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
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]
### 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]
  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]
  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]
  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]
  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]
### 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]
  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]
  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]
  nsIView@0x865e7a0{0,0,12250,6328 @ 0,0; p=0x8789238,m=0x87891d0 z=0,zp=(nil)}
y=-2800, w=12250, h=6328, absX=-2800, absY=-2800]

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

Closed: 15 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.