Windows 10: Happens in both web app (Chrome version 60.0.3112.113) and desktop app (Dynalist 1.0.38).
This happens in both an item or its note. Also, if there is nothing below the current item, the cursor just stays where it is.
Edit: It appears to be the same problem as was posted in Down arrow in note skips last line, though I originally thought this was a new problem as that one only deals with notes, so please excuse me if this was an unnecessary duplicate.
So I did some investigation around this, and unfortunately, I think it’s an extremely difficult problem that we’ll probably not be able to solve. The problem lies in the rendering engine that is Chrome (as well as chromium, which powers our desktop app).
So the short version is that Chrome considers the end of the current line and the beginning of the next line to be the exact same place. It actually ‘prefers’ that location to be the beginning of the next line (if you press left and then right, or vice versa, you’ll see that the cursor is no longer at the end of that line but is now at the beginning of the next line).
So this works fine on every line that’s not the second-to-last line because chrome internally remembers if it was at the end of the line or if it was beginning of next line, and if you press up or down, chrome can properly put the cursor at the end/beginning.
But it all breaks when you press down when the cursor is at the second-to-last line because Dynalist (js) thinks you’re at the beginning of the last line, and has to do something to allow you to jump to the next item (browsers doesn’t let you jump across items natively).
I find it hard to believe you could not put some kind of flag in your code to prevent this from happening. Otherwise, thank you for the reply, and I am sorry that you are unable to fix such a major bug from occuring in your text editor.
If you read the explanation, you’ll understand there’s no flag/fix we can make, until Chrome fixes how selection works in the Chromium core.
That’s the core issue. Unlike humans who can see where the cursor is, our program can only ask the browser “where is the cursor?” and browser will tell us it’s at the start of the last line, when you see it at the end of the second to last line.
And as Shida said, you can see this for yourself. Put your cursor at the very last position of a line. Press right, and then press left. You expect the caret to come back to where it originally was, right? But no, the caret rests at the start of the next line. Those two locations look different but they are considered exactly the same by Chrome internally.
It’s not an issue with Dynalist, unfortunately. We wish we could fix it. WorkFlowy has the exact same problem. Even the most basic contenteditable has this “major bug”.
(You can see all the source code of this demo here: https://jsfiddle.net/f9e1zyat/7/, it’s just a plain contenteditable, just to demo the issue is not from our code)
There are two lines of “s” in that box. Try position your cursor at the end of the first line – it’s very hard, most of the time your cursor would land at the beginning of the second line. But occasionally you would succeed. After having your cursor at the end of the first line, press Right and then Left again. The cursor is back to the beginning of the 2nd line.
Lots of developers have complained this to the Chromium team, and it’s their decision to not change the current behavior, for their own reasons. We find it hard to believe too, but unfortunately after spending lots of hours investigating, we have determined it’s not something we can fix. As an extreme example, it’s like a user’s display is broken and Dynalist shows up in yellow background color rather than white. We feel bad for the user, but there’s really nothing we can do. Really sorry for this.
One thing we can do is to make it really hard to put the cursor on the end of a line, just like in the demo page. So when you try to put the cursor on the end of a line, it would jump to the beginning of the next line. Unfortunately I think that would be quite annoying as well, even more annoying than the current state.
I think I understand better now. I didn’t realize that the program was dependent on Chromium for the cursor position to that extent. That’s definitely an unfortunate problem on Chromium’s part.
I should not have snapped, you did nothing to warrant that. Thank you so much for the detailed explanation (with examples), even though I was rather rude about it, and I hope you will accept my sincere apology!
That’s what I noticed as well (the miscommunication), and I’m glad my explanation works better this time around!
And no, you didn’t sound rude at all (trust me I’ve had much worse encounters), so no need for apology! Just wanted to clear things up and hopefully not leave the impression that we didn’t try hard enough to fix this bug. I get how annoying the issue is (), and we really want to fix it if that’s possible!
We’ll come back from time and time and see if Chromium fixes the issue or at least provides a workaround for this. If that happens, we will be able to fix it too