Starting from scratch, what are the steps to make the bug happen? The fewer the steps, the better.
Plug a physical keyboard into an android phone (e.g. a Bluetooth keyboard), and use ctrl functions (e.g ctrl+a (select all), ctrl+c (copy) etc.) in the official dynalist app or on mobile web.
Expected result
What do you expect to see after carrying out the steps above?
Afterwards, app should continue to operate as normal.
Actual result
Instead of the expected result, what happened?
App enters a weird âselect modeâ where when you try to tap on an item to edit it it selects it instead (it basically appears like ctrl becomes âlockedâ), see below:
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?
I have only replicated this on android but it happens both in the app and on the Web (on mobile) - have replicated issue across three android phones.
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.
It certainly seems ctrl is becoming locked on somehow as this is of course the function of control, but pressing ctrl again doesnât stop the behaviour - I havenât found any way to get rid of it and usually have to restart the app, which suffice to say, is frustrating.
Iâve seen this behavior with soft keyboards too, such as Hackerâs Keyboard. In that case though, tapping the Ctrl key a few times usually fixes the problem.
Thanks for the validation Craig! Yes ive seen it with hackerâs keyboard too (which has a soft ctrl key for the record, and I should have mentioned above). In my experience I would say mashing ctrl again âsometimesâ fixes it, rather than âusuallyâ though
First of all, I wasnât able to reproduce the issue with a bluetooth keyboard. After using Ctrl+C/V/A, it seems to work fine.
@Stephen_Dewitt do you encounter this after using Ctrl every time or just sometimes?
Although I couldnât reproduce the issue, itâs most likely from the âselect non-adjacent itemsâ feature on desktop. While holding Ctrl, you can click items to select them.
Now Iâm not sure if the Ctrl getting stuck is a hardware problem, or a driver problem (hardware releases Ctrl but somehow this is not sent to the client.
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!
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).
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)?
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.
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?
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.
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.
