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

Status: VERIFIED FIXED

(Core :: Web Painting, defect)

Description

[Phil Endecott]

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
elements.

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

[Phil Endecott]

Attachment: Demo of problem

Comment 2

[Mats Palmgren (inactive)]

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)

Comment 3

[Boris Zbarsky [:bzbarsky]]

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...

Comment 4

[Phil Endecott]

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?

Comment 5

[Boris Zbarsky [:bzbarsky]]

Anything you can do would be great.  I, personally, have no idea what's going on
here...

Comment 6

[Gervase Markham [:gerv]]

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:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 7

[Phil Endecott]

(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
present.
(In fact, why is this Unconfirmed anyway?  Boris says he saw the bug in comment #3.)

Comment 8

[Boris Zbarsky [:bzbarsky]]

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
problem....

Comment 9

[Martijn Wargers (dead)]

Attachment: 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.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Are we painting before we've actually repositioned the widget, somehow?

Comment 11

[Phil Endecott]

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?

Comment 12

[Martijn Wargers (dead)]

Attachment: testcase3, using non-random movement

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

[Phil Endecott]

Attachment: Screengrab of testcase 3 on a slow Linux machine

Here's what I see on my Linux box when I try testcase3.  Sorry about the quality; this is a camera screenshot.

Comment 14

[Martijn Wargers (dead)]

This seems fixed in my debug build that has the frame display lists patch in it.

Comment 15

[Martijn Wargers (dead)]

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

[Phil Endecott]

(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.

Comment 17

[Mats Palmgren (inactive)]

Verifying, SeaMonkey Linux.