Closed
Bug 47742
Opened 25 years ago
Closed 19 years ago
'Position:fixed' object with 'visibility:hidden' becomes visible briefly when it is moved.
Categories
(Core :: Web Painting, defect)
Core
Web Painting
Tracking
()
RESOLVED
FIXED
People
(Reporter: val, Assigned: roc)
References
Details
(Keywords: dom0, testcase)
Attachments
(1 file)
|
683 bytes,
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.
|
||
Comment 1•25 years ago
|
||
|
|
||
Comment 2•25 years ago
|
||
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
|
||
Comment 3•25 years ago
|
||
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
|
||
Comment 4•25 years ago
|
||
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
|
|
||
Comment 5•25 years ago
|
||
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
|
||
Comment 6•23 years ago
|
||
Is bug 129844 related to this? In that bug position:fixed; is not used, but its
kind of the same result at this.
|
||
Updated•21 years ago
|
Assignee: attinasi → roc
Status: ASSIGNED → NEW
Component: DOM: Level 0 → Layout: View Rendering
Priority: P3 → --
QA Contact: desale → ian
Target Milestone: Future → ---
|
|
||
Comment 7•20 years ago
|
||
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....)
|
Assignee | |
Comment 8•20 years ago
|
||
Beats me. Maybe you should turn on display list dumping (the calls to
ShowDisplayList) and see what you get?
|
|
||
Comment 9•20 years ago
|
||
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.
|
|
Assignee | |
Comment 10•20 years ago
|
||
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?
|
|
||
Comment 11•20 years ago
|
||
> 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...
|
||
Comment 12•19 years ago
|
||
I think this is WFM in my debug build that has the "frame display lists" patch in it (bug 317375).
Depends on: 317375
|
||
Comment 13•19 years ago
|
||
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
|
|
Assignee | |
Comment 14•7 years ago
|
||
|
||
Updated•7 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
•