Down arrow at end of second to last line skips last line

Steps to reproduce

  1. On any multi-line item, move cursor to the end of the second to last line.
  2. Press the down arrow key.

Expected result

Moves to next line down.

Actual result

Moves to next item.

Environment

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.

@Shida

Could you take a look at this? Thanks!

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 :grimacing:! 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 :slight_smile:

Yes, the bug still happens.

ā€‹Sorry for the late reply due to the holidays!

I was able to repro this bug, and it has been tracked and we will fix it as soon as we can! Thanks again for letting us know.

@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.

Sorry about that!

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ā€.

Hereā€™s a simple demo: https://jsfiddle.net/f9e1zyat/7/show/

(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 (:rage:), 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 :slight_smile: