Bug: mouse drops pieces prematurely during mouse drag of piece

I've been experiencing this issue for quite awhile and trying to determine if this is just a problem on my end. Today, I'm not so sure it is a problem with my setup but I think some weird bug with Lichess. This has only recently started to happen in the last couple of months.

Subject line says it all, basically, I use the drag and drop method for moves with Lichess. I don't use the click on from square, then click on to square method. What I've seen is that in odd instances, as I'm dragging a piece, it will drop prematurely on the wrong square and then be registered as a move. This seems to occur when there is a "rush" to make moves on both sides or a flurry to make a quick move. Typically, if I know which move I will be making, I will left-click and drag the piece to be ready to drop where I want as soon as the opponent makes a move, it is in this instance that the piece will be dropped prematurely especially if the opponent has made his move while I'm in the middle of dragging my move.

This didn't use to happen and I've never had issues even before I came to Lichess from FICS. I've checked my mouse, mouse connections, mouse battery (it is wireless). I've even changed to a wired mouse, still same problem. It is intermittent and really getting annoying.

I think this is a Lichess bug, but I'd like to be sure so that Lichess dev can fix this.

Is there anything that can be done to debug/troubleshoot this to determine if this is really a Lichess problem? Is there any kind of logging on the client side that can be enabled to help figure out if the mouse events are being processed properly? If server logging is the only way, then message me directly and set an appointment to log my client. I guarantee this "mouse" drop issue will happen, it happens all the time when I play. Usually, I can recover from it, but not always [sometimes the premature drop was better than my planned move 8-) ] .

Thanks.

I have not experienced this... I would say that it's a mouse issue, but you say it isn't as you've checked your mouse.

I still doubt it is lichess, but may I ask the OS and the browser you are using?

I have had an issue with ghost-clicking on a mouse before. I found a website like this one (you can also just google for a test site) to be helpful. Just do the actions you do when moving fast on lichess, and see if any unexpected input occurs. In this case, click and move the cursor around and see if you get a mousedown event.

dvcs.w3.org/hg/d4e/raw-file/tip/mouse-event-test.html

@TCF_Namelecc

I've got Windows 10 and using Firefox.

@WindowMaker

I'm not seeing any issues with the tester site. But, I wrote a small program to test my mouse and I didn't get any issues with that either. If this is a bug, it is a logic bug with Lichess in that it is seeing a mouseup event when there is none.

That is why I suggest some kind of logging here with the client side of Lichess or the Server side just to confirm or deny my assumption here because this is really hard thing to track down. Not just to log the events, but to log the processing that lichess does with those events.

I am having what sounds like the same issue Snorkelbuckle is describing, and roughly in the same timeframe (started happening suddenly a month or two ago, no instances of this happening previously). I've been trying to determine whether it's an issue with Lichess or if it's on my end. Originally I assumed it was on my end, but I haven't noticed it anywhere other than in Lichess. I came to the forum to search for whether anyone else is experiencing this and found this thread. I'm using a wired mouse, Chrome, and Windows `10.

*bump*

Is there any way to bump this to the developers, is there an official place to submit bug reports? I'm still having this issue and today it was even more pronounced. While holding my mouse button down to "move a piece", I hovered over a potential target squares and I could visibly see the moment when lichess "lost" the fact that I was dragging and moving a piece. I was essentially making a "pre-move", so I hovered over a potential target square while it was opponents move. Lichess highlights the target square as my mouse moves from square to square, but repeatedly, the piece was "released" by Lichess for no apparent reason. I had to re-drag the piece a few times before Lichess would allow me to complete the pre-move.

Very annoying.

That's 98% on your side. I'm 98% sure there is no way for Lichess code to think that a mouseup event ocurred without the OS / mouse generating it (that could also be a mouse down event [that would also cancel dragging]). I am not a Lichess developer, but I have researched Lichess front-end code and the script must first receive a mouseup event, otherwise it cannot respond and make a move (mousemove events cannot produce a move on their own, and a mousedown event will always cancel a dragging movement). I had the same problem occasionally when I used a mouse (the problem was that the mouse button was moving up and down a bit and that produced an accidental mouseup / mousedown event). I've never experienced it since switching to a graphics tablet. So in your case your mouse producing a second mousedown event or an accidental mouseup is the most likely scenario.

You can try logging events with this script:
document.addEventListener ('mousedown', function (e) {
console.log (e.type, e, e.timeStamp)
});
document.addEventListener ('mouseup', function (e) {
console.log (e.type, e, e.timeStamp)
});

//optional mousemove
/ * document.addEventListener ('mousemove', function (e) {
console.log (e.type, e, e.timeStamp)
}); * /

Once again my suspicion is this issue happened right after the rating range seek change was made. And guess when that happened? Two months ago. The timing fits.

@BerserkForItsOwnSake I'm pretty sure it isn't my mouse that is the problem, I've tried 3 different mice which I mentioned to you. I've also run code on my system to check my mouse function just in case it is driver issue. I'm sure it isn't. I feel strongly it is a bug with Lichess.

@Curious1 that is about the time I started noticing this issue. What is this "range seek" change that was made? Is it related to the logic of Lichess to detect mouse moves?