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:
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...
Summary: Moving a fixed div -> eratic mouse events & odd repaint → Moving a fixed div -> erratic mouse events & odd repaint
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 here...
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/
(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.)
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....
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.
Are we painting before we've actually repositioned the widget, somehow?
Assignee: nobody → roc
Status: UNCONFIRMED → NEW
Component: Layout: R & A Pos → Layout: View Rendering
Ever confirmed: true
QA Contact: layout.r-and-a-pos → ian
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.
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.
(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.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
Verifying, SeaMonkey Linux.
Status: RESOLVED → VERIFIED
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.