keymanapp
bug(mac): Southern Carrier keyboard not outputting correct symbols in beta
Describe the bug
I was testing out the new fv_southern_carrier keyboard using Keyman 17.0.285-beta and the keyboard stopped working as expected.
The sequence I typed was ts'iyawh
I expected ᙫᘓᐁᑋ
I received ᙫyᐊwᑋ
Another time, I received ᐪᔆ’ᐉyᐊwᑋ
Everything typed afterwards outputs either the latin value or the final form of each syllable. I attempted using the dead-key that is on the keyboard to separate the syllables but the error continued to occur. I tried typing the same sequence in different programs and had the same result each time (Microsoft Teams, Discord, Slack, Microsoft Word).
You may need to type a few sentences prior to this issue being reproducible. If needed, I can provide some sample text to type.
Reproduce the bug
No response
Expected behavior
ᙫᘓᐁᑋ
Related issues
No response
Keyman apps
- [ ] Keyman for Android
- [ ] Keyman for iPhone and iPad
- [ ] Keyman for Linux
- [X] Keyman for macOS
- [ ] Keyman for Windows
- [ ] Keyman Developer
- [ ] KeymanWeb
- [ ] Other - give details at bottom of form
Keyman version
17.0.285-beta
Operating system
MacOS Sonoma 14.4
Device
iMac
Target application
Microsoft Teams, Discord, Slack, Microsoft Word
Browser
No response
Keyboard name
fv_southern_carrier
Keyboard version
No response
Language name
Southern Carrier
Additional context
No response
Thank you for the bug report. We are all at a conference this week, so will look into this as soon as we are able.
I tried this out in Keymanweb.com, and it doesn't seem to work there. I downloaded the fv_southern_carrier.kmp file, and it does not contain a .kmx file.
@HopsAndHops do you have a desktop version of this keyboard in development? The published version is touch only
@mcdurdin Yes, the keyboard is in development. Let me know if you need to me send that over.
@HopsAndHops yes please, we will need the keyboard to repro the error here and trace the cause. Thanks!
I am getting the following in Keyman Developer for the keyboard that @HopsAndHops sent over:
Source files in Keyman Google Drive at https://drive.google.com/open?id=13ycW9N4VWFPEIn9_ErYYvtq24MUxB43p&usp=drive_fs (private link)
@mcdurdin, I get the same output that you see in Developer: ᙫᘓᗛ
This is with the latest beta code.
I am running Ventura on my developer machine, not Sonoma, but that seems like an unlikely explanation for the difference in behavior.
Looks like I'll have to rename again. Slack, the only app where I reproduced the issue, is being logged as compliant: Keyman is able to get the selection range and the context. However, I am unable to reproduce when running a version of Keyman that limits the context retrieval to 80 characters. Google Chrome actually is detected as compliant, too, as long as I am not using Google Docs within Chrome.
With Slack, the API attributedSubstringFromRange starts returning null if the range length is greater than 100. It does not throw any exception, and it is not clear why 100 would be the limit. I'm assuming that this limitation is coming from the application itself. If there is no stricter limitation applied by other apps, then the change to read only 80 characters of the context made through #11141 should fix this.