Double click select doesn't drag properly

closed

#1

Steps to reproduce

Write anything, but make sure it has multiple words
Double click the last word so it highlights, keep mouse down
Drag to the left, the highlight on the first word is lost
This works in Gmail
It works in this bug comment field I’m typing in right now :wink:
This is a ‘deep’ mouse behavior that is unsettling when it fails
I hope it’s a simple bug fix…

Expected result

What do you expect to see after carrying out the steps above?
When you drag, the selection keeps the original word

This is how I select all of my text (well, I usually drag right but sometimes I drag left)

Actual result

Instead of the expected result, what happened?

Environment

Which operating system are you using? Which browser are you using? If you’re using a desktop or mobile app, what’s the version number of Dynalist?


Additional information

Anything else you think would help our investigation, like a screenshot or a log file? You can drag and drop screenshots to this box. For large amount of text, try putting them into something like Pastebin.


Additional comments


#2

I’m not sure, what is “comment field”. It doesn’t work in note for me.

Normal behavior:

Peek%202019-01-21%2001-29

Actual behavior:

Peek%202019-01-21%2001-30


#3

Thanks, I’ve edited my original question to be more clear. I meant that in this bug comment field I’m typing in right now, I see the correct behavior. The stronger point is that everywhere in all browser based text editing, you get the correct double-click drag behavior. Only in Dynalist do you get this bug.

Thanks for the two gifs! They make the point well.


#4

Yeah… This is a product of how we handle markdown text editing.
It’s not exactly a simple “fix”.

We’ll put it on the back burner for now.


#5

That’s disappointing. Every single web-app on the planet does it right. This is something that affects me every day. I get you have priorities and can’t get at it right away. I just wish you didn’t brush my concerns away with a simple “it’s hard, not gonna happen” (with a strongly implied never)


#6

I’ve got a partial fix for this: As long as you keep the cursor within the item, it now works as expected.

I can’t seem to get the general case to work. When the mouse leaves the item, your selection now becomes a multi-item selection, which hides the original text box you were selecting, which makes the browser stop the cursor-selection action (and forget that you were in double-click-drag mode). When your mouse come back, it will be a fresh new selection.

But at least if the mouse were always inside the item (which is most of the time), it would work as expected now.

I’ll have the fix deployed within a few days!


#7

Thank you, I really appreciate the effort. Given that (I’m guessing) the majority of dynalist items don’t use markup, is there any chance that just for ‘markupless items’ this would behave normally?. It could be a cheap win.


#8

I believe it used to be like that years ago, but having the simple text behave differently caused a ton of problems because of the inconsistencies between elements on the page. It was then modified in favor of the simpler approach that was much less error-prone.


#9

OK, it’s great that you understand this bug is a significant problem (as you said, behaving two ways depending on markup caused big problems)

However, the issue isn’t inconsistency between items, its inconsistency with everything else on the planet. Dynalist is the ONLY product I know that selects text like this.

If it’s too hard to fix, that’s entirely your call. You are a small team with HUGE features to tackle. I understand that. I’m just trying to politely let you know that some us notice this problem on a daily basis and it’s frustrating.


#10

I’ve already worked out a fix. It should be out in a few days.


#11

This fix does not seem to be working as of March 18. The current dbl-click behavior changes the selection chunk from word to character as soon as you move a few pixels from original position, even if you stay within the same word. FWIW, this is my #1 frustration with Dynalist at this point. I run into it almost every time I do any editing of any item.


#12

I know it’s a small thing, it’s just selecting text, but that’s exactly why it’s a problem. It’s such a common thing that I bump into it every… single… time…


#13

What platform are you using? It seems to work for me on the web version right now.

I remember the fix had been out pretty soon after my last post.


#14

Well, I’m sorry, it’s working perfectly well now. I have no idea what happened. But it’s great. Again, sorry for my snarky comment. Great to see this working!


#15

No worries!


#16

Strange. It’s been working well on the web page but when I open my Dynalist app on a Mac, it shows the old behavior. Is there some way to force a refresh?


#17

Restarting the app should update it. The latest version is 1.1.16 right now.