This is going to lead down a rabbit hole. It probably isnât a bug in dynalist, but rather some poor design in the browser engines interacting with an old accessibility feature. I think ios systemwide dictate pre-dates siri and uses an older model, but maybe thats changed.
We have safaris rendering engine running in chromium running in electron, and ios dictation on top of that. The bug could be blamed on any of these layers.
Dynalist uses âeditable divâ elements. You can insert chunks of texts into them with javascript, or you can type individual keys which triggers keydown and keyup javascript listeners. The latter would be what triggers something like a popup. The former is how ios dictation inserts text in chunks as it understands it, rather than as individual keypresses.
Chrome on desktop has various accessibility flags that can be toggled on and off, because they know so much of accessibility is broken half the time. You toggle the flags until it works.
For me, I notice on mac that there are two speech recognition engines.
-
Accessibility dictate in the keyboard settings. itâs offline. It doesnât work in dynalist at all on Chrome. text will appear, but wont save to an item unless you press a key on the keyboard before clicking away. But in safari, it does work.
-
Siri dictate. it uses the internet. Itâs a lot more accurate, and does seem to work in both chrome and safari. @ and ! wonât trigger anything still though, due to that âchunkâ input method I mentioned.
Anyway, yeah, maybe in a new version of ios years down the line Apple will fix their dictate feature so it triggers javascript listener events, but it currently doesnât.