Windows 10: Happens in both web app (Chrome version 60.0.3112.113) and desktop app (Dynalist 1.0.38).
Additional information
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).
Hi @NeedsCoffee, sorry for digging this up ! Weāre cleaning up the bugs and would like to know if the bug is still happening to you? If not weāll close this bug
@NeedsCoffee sorry for the mistake above, we are not able to fix it, please see Shidaās reply on Sept 4. I didnāt carefully look at the thread before tracking it.
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: Edit fiddle - JSFiddle - Code Playground, 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