No feedback when using Backspace while typing in Kannada language using Nudi 6.1 software #15822
Comments
|
Note from the user: A workaround for this is to use shift+backspace. |
|
My testing does not confirm the range of versions mentioned in the initial comment i.e. this does not work for me with NVDA 2023.2, and does work as expected in 2023.1. Bisect shows that this has been introduced in PR #14708 |
|
My guess is that Nudi6.1 captures the backspace key and then re-sends it for some reason. Previously, we delayed slightly when sending keys, which would mean that any keys sent by an app which captured a key sent by NVDA would be ignored during that period. Now that we don't delay, we only ignore the key sent by NVDA itself, but that doesn't include any keys captured and sent by, for example, Nudi6.1. I'm not really sure what to do about this except put the delay back, but that would reintroduce a significant performance loss (15-40ms) for all users for cursor keys, backspace, etc. |
|
Actually, one thing we could try is this, as I discussed in #14708 (comment):
I'm not convinced it'll work, but it's worth a shot. I've pushed a try build with this approach. It will arrive here soon. |
|
I was unable to test with a binary try build (as it failed to finish for some reason), but testing with the branch |
|
Thanks everyone! That try build doesn't seem to have build. Have you got a link to the one you got to work please? |
seanbudd
added
app-specific
p4
|
I have tested running from sources. Perhaps you can just ask Michael or Sean to re-trigger the build. |
|
Ping @jcsteh - there appears to be an issue with the new code which is preventing the build - are you able to have a look when you get a chance please? |
|
Is this even after a re-trigger? In the first build I pushed, it seems to get stuck in a Chrome system test, but I don't know what because the console log is not particularly useful. |
|
If I had to guess, I'd say we're injecting a key, but that key never gets received by NVDA's keyboard hook for some reason. That would suggest it gets swallowed by something else or that our keyboard hook couldn't catch it for some reason. That's definitely one danger of this approach. I guess I could add a small timeout when waiting for the injected key, but that feels pretty hacky. |
|
To make matters more fun, I think we might be hitting the AppVeyor job time limit here, so even if we uploaded an NVDA log from the test run, it wouldn't actually get uploaded because the job gets killed. |
|
And trying a third time because I spotted some ways I could tighten things up and I'm a perfectionist. |
|
Indeed I am very grateful to you all. |
|
after installing nvda_snapshot_try-injectEvt-30139,19bd9384.exe and |
|
@smbgsrini Just to clarify: are there any differences in behavior with the |
|
Sir,
nvda_snapshot_try-injectEvt-30139,19bd9384.exe as compared to NVDA
2022.4 these both behaving same while typing Kannada text. nvda2023.3
is not announcing deleted character by pressing backspace key.
…On 07/12/2023, Łukasz Golonka ***@***.***> wrote:
@smbgsrini Just to clarify: are there any differences in behavior with the
`nvda_snapshot_try-injectEvt-30139,19bd9384.exe` as compared to NVDA
2022.4?
--
Reply to this email directly or view it on GitHub:
#15822 (comment)
You are receiving this because you were mentioned.
Message ID: ***@***.***>
--
Srinivasamurthy B G,
mo: 9035911023
blog: www.samaajakkaagi.blogspot.com
|
|
Hi @jcsteh Given your fix seems to solve this problem, are you planning to submit it as a PR? |
|
Yeah, I'll submit a PR when I get a chance. |
|
In nvda_2024.1beta1 has same problems which I mentioned through #Qchristensen |
Fixes #15822. Summary of the issue: With "Handle keys from other applications" enabled, NVDA interferes with certain software which intercepts and re-transmits keyboard commands such as Nudi6.1. For example, this makes it impossible to use backspace while this software is running. Description of user facing changes Backspace now works correctly when using Nudi6.1 with NVDA's "Handle keys from other applications" setting enabled. Description of development approach Before #14708, we delayed slightly when sending keys, which would mean that any keys sent by an app which captured a key sent by NVDA would be ignored during that period. After #14708, we only ignore any keys received while NVDA is sending keys, but that doesn't include any keys captured and sent afterward by, for example, Nudi6.1. This could result in a loop where NVDA kept receiving the key it sent (re-transmitted by the other app) and sending it again. To fix this, we now explicitly wait for the key sent by NVDA (e.g. backspace) to be received by the keyboard hook before we stop ignoring keys and thus return from KeyboardInputGesture.send(). This means that if another application intercepts this key and re-transmits it, we will wait for that re-transmission and ignore it. We use a kernel event so that the notification from the keyboard hook can be handled as quickly as possible without being dependent on the system timer resolution. There is a chance that a key will be intercepted and never re-sent. To deal with this, we wait for a maximum timeout of 10 ms. This means that in the best case scenario, nothing intercepts a key sent by NVDA and we return almost immediately. In the worst case scenario, we wait between 10 and 30 ms (depending on the system timer resolution), which is no worse than the situation before #14708.
|
Yet to be find solution
…On Wed, 27 Dec, 2023, 7:14 am Sean Budd, ***@***.***> wrote:
Closed #15822 <#15822> as
completed via #15957 <#15957>.
—
Reply to this email directly, view it on GitHub
<#15822 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/BEQUOEEU4DH65H74QEZOTNTYLN4RLAVCNFSM6AAAAAA7YQ22L2VHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJRGM2DCNZZG42TAMY>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
) Fixes nvaccess#15822. Summary of the issue: With "Handle keys from other applications" enabled, NVDA interferes with certain software which intercepts and re-transmits keyboard commands such as Nudi6.1. For example, this makes it impossible to use backspace while this software is running. Description of user facing changes Backspace now works correctly when using Nudi6.1 with NVDA's "Handle keys from other applications" setting enabled. Description of development approach Before nvaccess#14708, we delayed slightly when sending keys, which would mean that any keys sent by an app which captured a key sent by NVDA would be ignored during that period. After nvaccess#14708, we only ignore any keys received while NVDA is sending keys, but that doesn't include any keys captured and sent afterward by, for example, Nudi6.1. This could result in a loop where NVDA kept receiving the key it sent (re-transmitted by the other app) and sending it again. To fix this, we now explicitly wait for the key sent by NVDA (e.g. backspace) to be received by the keyboard hook before we stop ignoring keys and thus return from KeyboardInputGesture.send(). This means that if another application intercepts this key and re-transmits it, we will wait for that re-transmission and ignore it. We use a kernel event so that the notification from the keyboard hook can be handled as quickly as possible without being dependent on the system timer resolution. There is a chance that a key will be intercepted and never re-sent. To deal with this, we wait for a maximum timeout of 10 ms. This means that in the best case scenario, nothing intercepts a key sent by NVDA and we return almost immediately. In the worst case scenario, we wait between 10 and 30 ms (depending on the system timer resolution), which is no worse than the situation before nvaccess#14708.
) Fixes nvaccess#15822. Summary of the issue: With "Handle keys from other applications" enabled, NVDA interferes with certain software which intercepts and re-transmits keyboard commands such as Nudi6.1. For example, this makes it impossible to use backspace while this software is running. Description of user facing changes Backspace now works correctly when using Nudi6.1 with NVDA's "Handle keys from other applications" setting enabled. Description of development approach Before nvaccess#14708, we delayed slightly when sending keys, which would mean that any keys sent by an app which captured a key sent by NVDA would be ignored during that period. After nvaccess#14708, we only ignore any keys received while NVDA is sending keys, but that doesn't include any keys captured and sent afterward by, for example, Nudi6.1. This could result in a loop where NVDA kept receiving the key it sent (re-transmitted by the other app) and sending it again. To fix this, we now explicitly wait for the key sent by NVDA (e.g. backspace) to be received by the keyboard hook before we stop ignoring keys and thus return from KeyboardInputGesture.send(). This means that if another application intercepts this key and re-transmits it, we will wait for that re-transmission and ignore it. We use a kernel event so that the notification from the keyboard hook can be handled as quickly as possible without being dependent on the system timer resolution. There is a chance that a key will be intercepted and never re-sent. To deal with this, we wait for a maximum timeout of 10 ms. This means that in the best case scenario, nothing intercepts a key sent by NVDA and we return almost immediately. In the worst case scenario, we wait between 10 and 30 ms (depending on the system timer resolution), which is no worse than the situation before nvaccess#14708.
) Fixes nvaccess#15822. Summary of the issue: With "Handle keys from other applications" enabled, NVDA interferes with certain software which intercepts and re-transmits keyboard commands such as Nudi6.1. For example, this makes it impossible to use backspace while this software is running. Description of user facing changes Backspace now works correctly when using Nudi6.1 with NVDA's "Handle keys from other applications" setting enabled. Description of development approach Before nvaccess#14708, we delayed slightly when sending keys, which would mean that any keys sent by an app which captured a key sent by NVDA would be ignored during that period. After nvaccess#14708, we only ignore any keys received while NVDA is sending keys, but that doesn't include any keys captured and sent afterward by, for example, Nudi6.1. This could result in a loop where NVDA kept receiving the key it sent (re-transmitted by the other app) and sending it again. To fix this, we now explicitly wait for the key sent by NVDA (e.g. backspace) to be received by the keyboard hook before we stop ignoring keys and thus return from KeyboardInputGesture.send(). This means that if another application intercepts this key and re-transmits it, we will wait for that re-transmission and ignore it. We use a kernel event so that the notification from the keyboard hook can be handled as quickly as possible without being dependent on the system timer resolution. There is a chance that a key will be intercepted and never re-sent. To deal with this, we wait for a maximum timeout of 10 ms. This means that in the best case scenario, nothing intercepts a key sent by NVDA and we return almost immediately. In the worst case scenario, we wait between 10 and 30 ms (depending on the system timer resolution), which is no worse than the situation before nvaccess#14708.
Steps to reproduce:
Received via email
Using Nudi6.1 software. (you can download from below link.)
https://kagapa.in/kannada/sites/default/files/downloads/Nudi-6.1/Nudi_6.1_setup.exe
Type any text and then use backspace to remove any characters.
Actual behavior:
With NVDA's Keyboard setting "Handle keys from other applications" checked, user receives the following error:
"71 hotkeys have been received in the last 1812ms.
Do you want to continue?
yes no
(see #MaxHotkeysPerInterval in the help file)"
With this option disabled, the action works, however with no feedback from NVDA.
(Regarding this setting, the user guide does note that "Certain users may wish to turn this off, such as those typing Vietnamese with the UniKey typing software as it will cause incorrect character input")
The user advised that when trying the same thing with NVDA 2022.4, they do not receive the error. But when using NVDA 2023.1 or later, they do.
Expected behavior:
Ideally the user should get feedback about deleted characters, and no error.
NVDA logs, crash dumps and other attachments:
System configuration
NVDA installed/portable/running from source:
NVDA version:
NVDA 2023.3 installed
Windows version:
Windows 10.0.19045 Build 19045
Name and version of other software in use when reproducing the issue:
for typing Kannada, we use Nudi6.1 software. (you can download from below link.)
https://kagapa.in/kannada/sites/default/files/downloads/Nudi-6.1/Nudi_6.1_setup.exe
Other information about your system:
Other questions
Does the issue still occur after restarting your computer?
Yes
Have you tried any other versions of NVDA? If so, please report their behaviors.
Also tested with NVDA 2022.4 and NVDA 2023.1
If NVDA add-ons are disabled, is your problem still occurring?
Yes
Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's tools menu?
The text was updated successfully, but these errors were encountered: