Clicking end of line with a link sometimes puts cursor at the wrong location

[Alex_Pasternak]

Clicking end of a line with a link sometimes puts cursor at the wrong location. This does not happen every time, but regularly enough to be an issue multiple times a day.

Here’s a short repro video where the behavior occurs twice (AVI format as that is the only allowed extension I saw for this):
2019-10-01 DL clicking link.avi (568.6 KB)

You can see, since mouse clicks are captured in the video, that this is not a case of double-clicking by accident, and approximately the same area is clicked each time.

To be clear, expected is this, text cursor at end of unformatted text:

Instead, we have actual 1:

or actual 2:

Both of these require additional mouse clicks or keyboard navigation to get to the desired spot.

Env: MS Edge 79.0.287.2, macOS 10.14.6

Note that this is similar to previously reported issue, which was marked as fixed.

Cursor doesn't go where expected when clicking an item that contains a date or link

Steps to reproduce Create a new item with a date or link, for example this is a [test](http://talk.dynalist.io) item xyz Navigate elsewhere on the screen so that Dynalist parses the markdown, turning the text into a link. Now mouse over the created item, placing the cursor between y and z. Click. Expected result The text in that line expands to show markdown source, and the cursor is between y and z Actual result The text in that line expands to show markdown source, and the cursor is betwe…

[Erica]

Sorry, don’t think we can solve this without true WYSIWYG…

[Alex_Pasternak]

I don’t think I understand why that is. As per the repro video, at the time of the click, the text is formatted, and this operation usually works, I would say 80% of the time. To me that means it’s not a capabilities issue like WYSIWYG, but just a timing one instead. It’s like the code thread setting the cursor position doesn’t wait for the one detecting click location to complete. If I were solving it, I’d be debugging timing and inputs of those 2 pieces of logic.

[Erica]

Sorry about the late reply.

After carefully looking at the video a few times, it looks like the position is messed up when the cursor is moved ever so slightly while held down. So a quick mouse release should help. At 00:11~00:12, you can see that the cursor was placed in the right position for a split second.

Our guess is that if you moved your mouse after mousedown, the mousedown action will focus on the item, expanding the markdown, while the mousemove would position the cursor again. At this time, the markdown is already expanded, and the caret is unfortunately set directly under the mouse cursor.

Once we have WYSIWYG, this should be fixed now.