Double clicking in anything 2.4.x is unacceptably unreliable and loses the node

starchyrepair commented 1 year ago

Describe the bug.

When I double click a node to edit in 2.4.x, it often makes the node disappear completely. What's ACTUALLY happening is that it's relocating the node on the map to Saskatchewan, someplace WAY far away that can only be found by zooming out. It happens repeatedly, even if you find it, scattering nodes all over the place. I really miss the neat, reliable way the previous 2.3.x versions handled (just about everything) but losing nodes and creating random orphans is the worst. I'm using it with students and it's just not usually in these later versions.

Steps to reproduce:

On a PC - not sure if on Chromebook or Mac at the moment, double click a node to edit, after creating a new passage. Watch the node disappear as if it's being deleted.

Expected behavior:

I'd expect the passage/node to unfold to the editor.

Additional context on this problem.

No response

Twine version number

2.4.x

Does this problem occur with the web version of Twine or the desktop app?

Web

What operating system does this problem occur on?

Windows

If this problem is occurring with the web version of Twine, what browser does it occur on?

Chrome/Chromium

Presubmission checklist

[ ] I am interested in working on code that would fix this bug. (This is not required to submit a bug report.)
[X] I have done a search and believe that an issue does not already exist for this bug in the GitHub repository.
[X] If this problem is occurring with the app version of Twine, it still happens after I remove the user.css file from my Twine folder. (You would've added this file yourself. If you don't understand this question, you can safely check this box.)
[X] I have read and agree to abide by this project's Code of Conduct.

klembot commented 1 year ago

Do you see this bug in 2.7.0?

starchyrepair commented 1 year ago

Yes. Thanks.

On Wed, Jul 19, 2023, 7:36 PM Chris Klimas @.***> wrote:

Do you see this bug in 2.7.0?

— Reply to this email directly, view it on GitHub https://github.com/klembot/twinejs/issues/1426#issuecomment-1643018719, or unsubscribe https://github.com/notifications/unsubscribe-auth/A6SVG27IAKTHWD7444TXND3XRCKT7ANCNFSM6AAAAAA2PBMT4E . You are receiving this because you authored the thread.Message ID: @.***>

klembot commented 1 year ago

Hmm. I'm not sure what could be causing this problem, and I can't reproduce it myself. Three things might help (in order of effort):

Could you check your browser developer tools console (control-shift-J should do it) and see if any error messages appear when the passage gets yeeted?
Could you upload a sample story which is problematic for you?
Is it possible to take a screen recording of the problem occurring?

ylapointe commented 1 year ago

I am also having the same issue. I but I think I've narrowed it down a bit. However, it is inconsistent... it seems to only do the weird node teleport when I use my laptop touchpad AND only when using double tap (rather than the physical buttons). Sometimes it teleports, sometimes it won't. It ONLY does it if the window for that passage isn't already open. I'd say it happens 1 out of 5 tries.

As for what it's doing. It seems to teleport base on mouse position in relation to 0,0 on the canvas (top left corner). If you put the node in the top left corner and activate the bug by double tapping, its new position seems to move it directly to the mouse (with the top left corner of the node at mouse position). It seems to exponentially teleport the node farther depending on how far it is from 0,0. The further it is, the bigger the teleport distance.

To summarize:

the bug only activates when using touchpad double tap (not physical clicks)
the node teleports exponentially further base on its position from 0,0
it happens maybe 1 out of 5 times

edit: I am on version 2.7.0

klembot commented 1 year ago

@ylapointe are you using Windows or Mac, and which version of that operating system are you using?

What I'm afraid might be going on is that between the two taps, Twine "sees" a large movement of the cursor and interprets it as a drag. Especially if you're using a trackpad, it's easy for your finger to move a bit on the second tap (at least, this happens to me sometimes). Right now Twine ignores drags that are less than 1 pixel, which is possible in some OSes.

If this is all true, it will be tricky to distinguish a spurious drag from someone really truly dragging passages a far distance in a short amount of time.

ylapointe commented 1 year ago

Windows 11

My mouse is not moving during the double tap, and my trackpad has built-in tap protection to prevent the mouse from moving when taps are detected. It's also very consistent how far it moves from 0,0, It exponentially moves down and to the right. It never moves left or up. I will try to record the bug when I get some time. It might give you a better idea what's going on if you can see it in action.

Edit: I am on a preview release build of win11, so that may have something to do with it, but I'm not sure.

hituro commented 1 year ago

I had the same thing happen to me yesterday, on MacOS, and while using a mouse not a trackpad (the trackpad was turned off). As described by @ylapointe, I double-clicked a passage and it moved down and to the right, probably about as far as my mouse was away from 0,0

Also on 2.7.0

ylapointe commented 1 year ago

OK, so I found a consistent way to reproduce the bug. If you triple tap (or more) and hold, the moment you move the cursor it teleports. I'm not sure about @hituro's case, but for me this only happens with my touchpad. I tried opening up the debug console to see if I could find out what it's doing. Sure enough, under the Elements tab/Properties, whatever is going on with className: and classList: seem to be related to the issue. There are two different behaviors depending on if you use mouse or trackpad.

Here's a video of it; https://www.youtube.com/watch?v=OB4NXyP45FA

The first few double clicks were with a mouse. (0:00-0:06)
The next few double clicks were with my touchpad using taps. (0:09-0:13)
The final few clicks were using triple taps and holding, which causes the glitch as soon as you move the cursor. (0:15-fin)

klembot commented 1 year ago

@ylapointe awesome investigation! I am able to reproduce the problem when triple-tapping then starting a drag. Thanks to your work, we should be able to fix this.

klembot commented 1 year ago

@ylapointe @hituro This is frustrating. I came back to this issue to fix it, but now I can't reproduce the problem with triple-tapping anymore. It might be because I've upgraded browsers, or because I'm on a different OS version now (macOS Sonoma), or the Electron version used with Twine is newer... or my timing is off. I noticed that when I triple-tap, an editor is opening for me after the second tap, but it doesn't in the YouTube video from August.

I've made a debug build of Twine that logs more information about drags under Help > Troubleshooting > Show Debug Console that I'm hoping can shed light on the issue.

Mac
Windows

Can you see if you can reproduce the problem there still, and if so, could you attach console logs when it happens? Right-click the Console panel and choose "Save as" to save to a text file.

Generally speaking, the sequence of logs for each drag should always be:

handleDragStart when you press the mouse button down.
handleDrag if you move the mouse while the button is down. You should see lots of these while dragging.
handleDragStop when you let go of the mouse button.
handleDrag timeout dispatched stop action immediately after the handleDragStop log.

If anything is out of order or we're missing a line during a drag, something is wrong.

ylapointe commented 1 year ago

@klembot it is still occurring for me. Here is the log

-1698624415937.log

klembot commented 1 year ago

@ylapointe Thanks for the log! It shows a bad sequence right at the start:

index-aaa4e67a.js:69 handleDragStart index-aaa4e67a.js:69 handleDragStop index-aaa4e67a.js:69 handleDragStart index-aaa4e67a.js:69 handleDrag index-aaa4e67a.js:69 handleDrag timeout dispatched stop action

I could repro the problem more readily by increasing the timeout to 100 milliseconds or higher. I have a potential fix but I'd like to confirm that it works for you. I named this version alpha2 to make it easier to confirm you have the fix installed and not the debugger version.

ylapointe commented 1 year ago

@klembot it has indeed worked! Thanks for the hard work!

klembot commented 1 year ago

@ylapointe awesome! Thanks so much for your testing.

klembot / twinejs