Closed
Bug 1303
Opened 26 years ago
Closed 26 years ago
[BLOCK] Can't move positioned elements with mousemove/clientX detection
Categories
(Core :: DOM: UI Events & Focus Handling, defect, P2)
Tracking
()
VERIFIED
FIXED
M7
People
(Reporter: angus, Assigned: joki)
Details
Here's a test case. When viewing this, you should see a blue box. You should be
able to mousedown on the box and drag it around. When dragging, the delta
movements are dumped via alert. In other words, if you move your mouse to the
right a few pixels, the stdout will say "Moving by: (5,0)" or something like
that to indicate it is trying to shift the DIV to the right by five pixels.
However, the DIV never moves. Upon closer inspection of the output, you'll see
that every mousemove event seems to cancel out the last one out:
Moving by: (5,0)
Moving by: (-5,0)
Moving by: (10,-2)
Moving by: (-10,2)
... etc. ...
Here's the test case / sample code. I bet it has something to do with
e.clientX/e.clientY
<html>
<head>
<script>
function doDrag(e) {
var difX = e.clientX-window.lastX;
var difY = e.clientY-window.lastY;
alert('moving by: ('+difX+','+difY+')\n');
var newX =
parseInt(document.getElementById("myElement").style.left)+difX+"px";
var newY = parseInt(document.getElementById("myElement").style.top)+difY+"px";
document.getElementById("myElement").style.left=newX;
document.getElementById("myElement").style.top=newY;
window.lastX = e.clientX;
window.lastY = e.clientY;
}
function beginDrag(e) {
window.lastX=e.clientX;
window.lastY=e.clientY;
window.onmousemove=doDrag;
window.onmouseup=endDrag;
}
function endDrag(e) {
window.onmousemove=null; // No equiv to releaseEvents in W3C DOM?
alert("\n Ending drag \n");
}
</script>
</head>
<body>
<div id="myElement" onmousedown="beginDrag(event);"
style="position: absolute; left: 40px; top: 40px; width: 100px;
background-color: blue;">
Test one two three
</div>
</body>
</html>
|
Assignee | |
Updated•26 years ago
|
Status: NEW → ASSIGNED
|
|
Assignee | |
Comment 1•26 years ago
|
||
So with the recent event changes this is a whole lot closer to working. There
seems to be two problems now. One, when you're over the div, the movement is
jumpy which probably indicates some sort of feuding coordindate systems. Two,
once the mouse leaves the div, all the events come through in the document
coord system. This makes the div drag around okay but the mouse isn't actually
over the div.
|
||
Comment 3•26 years ago
|
||
per leger, assigning QA contacts to all open bugs without QA contacts according
to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
QA contact re-assigned according to the product areas we're currently working
on.
|
|
Assignee | |
Updated•26 years ago
|
Target Milestone: M4 → M5
|
|
Assignee | |
Comment 5•26 years ago
|
||
Coordinate problems will be fixed but the change is too unstable for M4.
|
|
Assignee | |
Updated•26 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
|
|
Assignee | |
Comment 6•26 years ago
|
||
Fixed. Here's some test code.
<HTML>
<BODY>
<div onclick="dump('click div 1\n');">
Div 1
</div>
<div style="position: absolute; top: 100px; left: 100px;" onclick="dump('click
div 2\n');">
Div 2
</div>
</BODY>
</HTML>
|
|
Assignee | |
Comment 7•26 years ago
|
||
Oops, wrong bug.
|
|
Assignee | |
Updated•26 years ago
|
Status: RESOLVED → REOPENED
|
|
Assignee | |
Updated•26 years ago
|
Resolution: FIXED → ---
|
|
Assignee | |
Updated•26 years ago
|
Status: REOPENED → ASSIGNED
|
|
Assignee | |
Updated•26 years ago
|
Target Milestone: M5 → M6
|
|
Assignee | |
Comment 8•26 years ago
|
||
Moving out to M7
Severity: normal → blocker
Summary: Can't move positioned elements with mousemove/clientX detection → [BLOCK] Can't move positioned elements with mousemove/clientX detection
|
|
Assignee | |
Comment 10•26 years ago
|
||
Okay, the big stopper here was just the bad clientx/y coords in subviews. All
fixed now. You may need to take the alert out of the test to verify the fix but
you can then happily drag the layer, oops, div (dhtml flashback, I believe I
fixed this same bug about two years ago) all over the page.
|
||
Updated•26 years ago
|
Whiteboard: just need to mark fixed?
|
|
||
Comment 11•26 years ago
|
||
I see a checkin from joki and comment above but the bug isn't
marked fixed yet. can we do that base on the update to
mozilla/layout/ events/src/nsDOMEvent.cpp
or other earlier checkin?
Fixing event clientx/y coords to have the right value even in subviews
|
|
Assignee | |
Updated•26 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 26 years ago → 26 years ago
Resolution: --- → FIXED
|
|
Assignee | |
Comment 12•26 years ago
|
||
Sorry, that last commment from me was supposed to accompany setting the bug
fixed but I forgot the last part.
|
||
Updated•26 years ago
|
Status: RESOLVED → VERIFIED
Whiteboard: just need to mark fixed?
|
|
||
Comment 13•26 years ago
|
||
Tested using 6/16 build. Viewer works correctly. Per joki@netscape.com, I had to
remove the alerts for test to work in Apprunner. Verifying bug fixed.
|
||
Updated•6 years ago
|
Component: Event Handling → User events and focus handling
You need to log in
before you can comment on or make changes to this bug.
Description
•