Moving a fixed div -> erratic mouse events & odd repaint




15 years ago
9 months ago


(Reporter: spam_from_bugzilla, Assigned: roc)



Dependency tree / graph

Firefox Tracking Flags

(Not tracked)



(4 attachments)



15 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0 (Debian package 1.0-2)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0 (Debian package 1.0-2)

I have been experimenting with dragable divs, i.e. use mousemove events to
update left: and top: style attributes and so allow the user to drag around page

This works fine when the divs have position:absolute, but odd things happen when
I use position:fixed.  First, the div is redrawn much more frequently than in
the absolute case, though the background is repainted with aparently the same
frequency as in the absolute case, so a trail is left behind.

Second, and this is the more bizzare aspect, the actual mouse co-ordinates in
the event.screenX|Y properties seem to have eratic perturbations.

I will attach a demo.  Note that my PC is fairly old (500MHz) and I suspect that
the effect is less obvious with a faster box.

Two "dragable divs" are displayed, one absolute and the other fixed.  You can
drag them by their titles.  You should be able to see the different update rates
and eratic movement immediately.

At the top left of the page two counts are shown.  The first is a count of
mousemove events received, and the second is a "mouse odometer" summing the
absolute distance that the mouse seems to have moved based on the screenX|Y
values from the mousemove events.  A simple test is to move each div across the
screen and back.  If I do this taking about a second to do so the event counter
will record about 50 events in both cases.  I think that the fixed div is being
redrawn for each of these events, while the absolute div is redrawn only once or
twice.  For the absolute div the odometer will accumulate approximately the
distance travelled, as expected.  For the fixed div it will record approximately
two to four times the distance, explaining all the eratic jumpy behaviour.

Sorry this is a bit long and vague.  This is with FF1.0.  Works fine in Opera. 
Of course doesn't work at all in IE.

Reproducible: Always

Steps to Reproduce:

Comment 1

15 years ago
Posted file Demo of problem
The positioning works fine in my local debug build - I think Boris fixed this
recently.  Text selection occurs when I drag one box over the other though,
I'm not sure if that's a bug or not.
(You could try using '-moz-user-select: none;' when dragging occurs)
Hmm.. If you mean my GetScreenRect() fix, I'm afraid that's not it -- I see
problems in both this morning's trunk build and in my build with that fix...


15 years ago
Summary: Moving a fixed div -> eratic mouse events & odd repaint → Moving a fixed div -> erratic mouse events & odd repaint

Comment 4

14 years ago
Eratic movement still present in 1.8b.

Would it help if I tried to analyse the position values in the mouse events?  I
get the feeling that it might sometimes be doubling the displacement or
something like that.  Or do you experts already have a feeling about where the
problem is?
Anything you can do would be great.  I, personally, have no idea what's going on
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:

Comment 7

14 years ago
(In reply to comment #6)
> This bug has had no comments for a long time.

Sorry, I don't have time to download and test with a current build.
If anyone who already has a curent build installed would like to try the
attached demo it only takes about two seconds to see if the problem is still
(In fact, why is this Unconfirmed anyway?  Boris says he saw the bug in comment #3.)
It's not confirmed because I have no idea what component this belongs in and
because it's not obvious that this is the minimal testcase that shows the
Posted file testcase2
With this testcase, I can briefly see the fixed div at two spots - one at the
old spot and one at the new spot - while the script is running, when I've
clicked on the "moverandom fixed" button.
I don't see this happening when clicking on the "moverandom absolute" button.
Keywords: testcase
Are we painting before we've actually repositioned the widget, somehow?
Assignee: nobody → roc
Component: Layout: R & A Pos → Layout: View Rendering
Ever confirmed: true
QA Contact: layout.r-and-a-pos → ian

Comment 11

14 years ago
I've tried testcase2 on two machines.

On the slow (500MHz) Linux machine on which I originally found this problem, I
see probably all 100 of the random-repositionings on screen simultaneously. 
After pressing the button it takes about a second before anything happens, then
about another second to draw them all.  Then, all but the final one disappears.
 The button appears depressed while they are being drawn, and seems to be
redrawn unpressed simultaneous with the final update that tidies up the rest of
the screen.

On a much faster Windows machine I see something more like Martijn describes: I
think I see two simultaneous images, but possibly at two random positions; could
it be, perhaps, the first and the final iterations of the loop?

I'm curious to know if this is a slow/fast machine difference, or a
Windows/Linux difference.  Can someone with a fast Linux box or a slow Windows
box try it out?  Alternatively, can someone (Martijn?) try increasing the number
of iterations to 10000 and see what happens on a fast machine?
I guess this is a Windows/Linux difference. I use WinXP on a 600MHz Duron, but I see the fixed div at two spots with the testcase; increasing the loop to 1000 makes only the period during which I see those two spots longer.
With this non-random moving testcase, I can see the fixed div for a moment at his original spot and at the beginning of the loop place.

Comment 13

14 years ago
Here's what I see on my Linux box when I try testcase3.  Sorry about the quality; this is a camera screenshot.
This seems fixed in my debug build that has the frame display lists patch in it.
Depends on: 317375
This is fixed for me by bug 317375.
Phil, could you test again with your slow Linux box to see if the bug is fixed?
You need to use the latest nightly trunk build for testing.

Comment 16

14 years ago
(In reply to comment #15)
> This is fixed for me by bug 317375.
> Phil, could you test again with your slow Linux box to see if the bug is fixed?
> You need to use the latest nightly trunk build for testing.

Yes, it seems to be fixed for me in today's nightly build.  Thanks.

Last Resolved: 14 years ago
Resolution: --- → FIXED
Verifying, SeaMonkey Linux.
Component: Layout: View Rendering → Layout: Web Painting
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.