Ctrl bug on android mobile when using physical keyboard

Hi Erica, thatā€™s odd - were you on android? This has been consistent for me over several phones and platforms (chrome and the app itself) with both soft (as Craig above confirmed) and physical keyboards - could you try with hacker soft keyboard and see if you can reproduce it that way? I encounter this about 90 % of the time when using a ctrl function across all these devices / platforms / keyboards

I was able to reproduce the issue with Hackerā€™s keyboard.

Looking into it, but it could be very hard debug, without knowing how Hackerā€™s Keyboard implemented their Ctrl key. Weā€™ll try though, thanks for the report!

Iā€™ve got an idea on this when looking at our todo list.

We want to build a dedicated UI for bulk selecting on mobile, so the Ctrl+tap mechanism can probably be disabled altogether on mobile, which should solve your issue.

This sounds good Erica, although I sometimes intentionally Trigger this bug on mobile to multi-select, it is 10 times more annoying than useful so turning it off is ok with me!

1 Like

Hi @Erica, any update on getting this switched off on mobile? Its Driving me a little nutty!! Thanks :slight_smile:

Bumped priority, sorry for the long wait! That reason was that you seem to be the only one affected by this (there are lots of Dynalist users who use external keyboards, judged by the number of users who complained that Tab/Shift+Tab doesnā€™t work with external keyboard).

Sorry and I hope thatā€™s understandable!

1 Like

Thanks erica!

Hi @Erica, I saw with great excitement and appreciation the mention of fixing this bug on the last update

ā€œ[UX/minor] Disabled Ctrl+click to multi-select on mobile since Ctrl key sometimes get stuck when using external keyboard with the mobile app.ā€

I really am grateful you guys got to this ā€¦ unfortunately, nothing seems to have changed. Iā€™ve checked across two phones, both the dynalist android app (updated to latest version) and the mobile web version, and the same ā€˜sticky ctrl and clickā€™ bug is still there ā€¦ sigh - Iā€™m not sure if there was a mistake fixing this at Dynalist HQ, or perhaps this bug really doesnā€™t have anything to do with ā€˜ctrl and clickā€™ (although that seems unlikely to me).

Are you guys not now experiencing this issue in house on e.g. an android phone with ctrl function (e.g. using Hacker keyboard)?

Thanks!

Stephen

We havenā€™t released a new version yet.

The top of each weekly update reads ā€œThe features and fixes might arrive at the desktop and mobile app a few days later than the web version.ā€ Itā€™s because deploying a new web version is much easier, so we want to make sure itā€™s stable before deploying to other platforms. Otherwise if we need to fix something small, weā€™ll need to release a mobile app version with release notes ā€œfix derpā€ā€¦

Next time you see Dynalist app is updated, it should be fixed. If not, you can post in this thread.

I hope that helps!

Ah phew, ok Iā€™m excited again! :slight_smile:

1 Like

Hi Erica, I donā€™t mean to be a pest, and Iā€™m really grateful this has come to the dynalist mobile app - I just wanted to check if this will roll out to mobile web at some point as the big is still occurring there with no change?

Thank you very much,

Stephen

Hi Stephen,

Are you using Dynalist on both platforms?

The check we added was for mobile app environment specifically, and we donā€™t want to disable Ctrl based on guessing itā€™s a mobile browser (it might not be accurate) or based on screen size. That was our reasoning.

Hi Erica,

Yes 90% of the time I use it in a ā€˜always onā€™ pop up browser as I use dynalist so much to capture everything in my life even fairly short load times arenā€™t workable - this is a real shame for me but I do see the issue - However, the mobile version of the dynalist website is so completely different to the desktop Web version (e.g. it has a slider bar, etc etc) that I thought there must be some indicator of whether the user is accessing the mobile Web or desktop Web version? Couldnā€™t this be checked for in the same way? I canā€™t see how this could lead to false positives

They do look different, but if you resize the desktop version to be really narrow, it looks the same. You could try that out.

Yeah, the concern is false positives. We donā€™t want to disable Ctrl for someone whoā€™s using Dynalist at 1/4 of their screen width to better take notes, if that makes sense. There are ways to try to tell if itā€™s a mobile browser, of course, but that practice is called user agent sniffing which we try to avoid doing if possible.

I guess we can do that for now, since I think youā€™re the only person bothered by this issue, the current fix is pointless if it doesnā€™t actually fix it for you.

1 Like

Woop, thank you! :slight_smile:

Hi @Erica, this is actually only currently fixed on the dynalist app, but it still exists on mobile web (that we discussed just above) unfortunately.

Sorry we forgot about that part.

The iOS app is much faster now, the speed should match that of Safariā€™s. Any reason why you prefer the mobile web over the app? :confused:

Iā€™m on Android actually - the mobile app continues to be unusable for me and many others as it is so slow (typing in particular) - also certain Web apps come with a notification which keeps dynalist in ram (i.e. so you donā€™t have to deal with reload times when android drops it)

I see.

Iā€™ve made the change and it should be available around a week from now. Sorry about the delay!

1 Like

Wonderful, thanks Erica! :slight_smile: