I'm playing with the HTML5 drag and drop and tracking the mouse position while dragging.
OffsetX and OffsetY works awesome until you release the mouse, the offsets jump to a negative number on the last drag event dispatched
here's the html:
<div id="dragger"></div>
<div id="console"></div>
here's the css:
#dragger{
-webkit-user-drag: element;
width: 100px;
height: 100px;
background: hsla(200, 100%, 50%, 0.4);
}
and the js
$('#dragger').bind('drag', function (e) {
$('#console').html(e.originalEvent.offsetX);
})
You can also test out at http://jsfiddle.net/Eu2mz/5/
Also I'm just trying to get it to work in webkit for now.
I don't know why but when dragging over or dropping outside of the draggable object will change the offsetX
, offsetY
, clientX
, clientY
etc properties to some unintelligible number.
The fix is to preventDefault
on the document drop and dragover events.
document.addEventListener("drag", function( event ) {
var element = document.getElementById('console');
element.textContent = event.clientX;
}, false);
document.addEventListener("dragover", function( event ) {
event.preventDefault();
}, false);
document.addEventListener("drop", function( event ) {
event.preventDefault();
}, false);
#dragger{
width: 100px;
height: 100px;
background: hsla(200, 100%, 50%, 0.4);
}
<div draggable="true" id="dragger" ondragstart="event.dataTransfer.setData('text/plain',null)"></div>
<div id="console"></div>
I had the same problem and came up with a solution that will work 99.99999% of the time. the explanation is below:
eng.window.addEventListener(
"drag"
,function(event){
//If both screenX and screenY are 0, likely the user just released.
if(!event.screenX && !event.screenY) return;
//Your code here
}
);
I looked through the event returned on releasing the mouse and compared it to the event immediately before, and couldn't find anything that will work in 100% of the cases- there's no easy "buttonPressed" feature or the like hidden inside the object.
I did see though that every single measure of cursor position is changed when you release: clientX
, layerX
, offsetX
, pageX
, screenX
, and regular x
/y
. They all default to the top-left value possible, which may be the top-left corner of the window- or the screen.
But what is the likelihood that your user will go into fullscreen mode drag and drop an element into the very top-left pixel of their screen? (In Chrome for me, screenX
is actually set to the left edge of the window; but screenY
takes Chrome's HUD into account)
So while the above won't work in that 1 fringe case (that your users will likely never-ever run into), it will work every other time.
Tested in Chrome.
I am reporting this as of Chrome version 68.* and earlier so it may be fixed later on. Been pulling my hair out for ages as I have two different computers, both with Windows 10 and the exact same version of Chrome. On one, the HTML 5 ghost layer doesn't skip forward when you start to drag it yet (works perfectly) on the other computer it skips!
Finally discovered that this happens when you change the font size on your Windows Display Settings. (Right click on desktop -> Display Settings - > Scale and Layout).
If you change the font size to be anything other than 100% it messes up the ghost. I have a computer with a 4k monitor that needed 150% font size and my other stayed at 100%.
Doesn't seem to be happening in Opera or Edge and hav'nt had time to test all browsers. I have already reported it to Google.
Basic example
http://jsfiddle.net/w9uyc5k4/
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With