`sendKeyStroke` has varying results if num lock is on or not

Issues - Game Events
,
1

Issue Description:

sendKeyStroke functions differently depending on if the user has num lock enabled or disabled. If num lock is disabled, the key strokes seem to act appropriately. But if num lock is enabled, the function sends unexpected keys.

For reference, our app is sending home, delete, up, and down key strokes[1]. If the user has num lock enabled then instead of the expected results we see a series of numbers and decimals, as if the user was pressing a corresponding key on the numpad.

[1] I wasn’t able to find documentation on the accepted input for the keyString parameter, so if these values are unexpected please let us know.

Steps to reproduce:

Call sendKeyStroke("up") with num lock disabled, and observe the expected results. Enable num and observe that OW sends an 8 keystroke instead.

Impact for my app: [low, mid, high, show-stopper]

Low - users can work around the issue by disabling num lock, it’s just an inconvenience.

2

@bryan thanks for the info. We will check it out and update you.

3

hi @bryan,

We had some issues with this API on previous versions. We released a fixed in OW version 138.

Can you please make sure that you are using the latest version of OW client? You can download the developer’s version (which is 139v), try and update us.

4

@bryan ok I test it now (on version 139, but it should work on previous versions as well) - and it’s working as expected:

When I call sendKeyStroke("up") the function always forwards it as up arrow, regardless of the num lock state.

BTW, the valid values for this function are the same as the Microsoft Key enum. (I will add it to the docs).

Thanks.

5

Hey @eransharv , thanks for looking into the issue.

BTW, the valid values for this function are the same as the Microsoft Key enum. (I will add it to the docs).

Thanks! I’ve updated our implementation to use the correct casing for the keyString parameter.

Can you please make sure that you are using the latest version of OW client?

Sorry for not including my OW client version in my original post. I was testing on originally on version 137 but have updated to 139 to re-test.[1] After updating to 139, I’m still seeing the original issue if numlock is enabled on my keyboard.

In our use case, we’re attempting to send multiple sendKeyStroke events in quick succession:
["Up", "Up", "Up", "Home", "Shift+End", "Delete", "N", "A", "M", "E", "Down", "Home", "Shift+End", "Delete", "P", "A", "S", "S"]
with the expectation that the in-game text fields will be auto-filled.

But if numlock is enabled then we’re seeing the following results:

Annotation%202019-11-21%20111914
Annotation%202019-11-21%201119141602×927 466 KB

where it appears that the following keystroke events are being mapped:

{"Up" '8'
"Home" '7'
"Shift+End" '1'
"Delete" '.'}

Is there any more information you can think of that might be helpful so that we’re seeing the same results?
We’re seeing the issue consistently here, and have seen our beta users also experiencing the issue.

[1] Not sure if this is expected, but I had to uninstall/reinstall the OW client to get the updates.
Using the “Check for Updates” button in-client kept saying I was on the latest version at 137,
even after a restart.

6

@bryan

  1. Can you clarify what exactly is the “Up Up Up…”? 2. When you press the above keys manually, is it working as expected?
  2. When you press the series of keys manually, it’s working as expected?
  3. Did you try to “insert” some delay between the keystrokes? (I want to eliminate the suspicion that there is an issue when you auto-enter couple of chars in a row).
7
  1. Can you clarify what exactly is the “Up Up Up…”?

That’s the series of keystrokes that we’re attempting to send when the user presses “Auto-Fill”. Each string is a separate call to sendKeyStroke with the corresponding string.

sendKeyStroke("Up");
sendKeyStroke("Up");
sendKeyStroke("Up");
...
  1. When you press the series of keys manually, it’s working as expected?

Yes, manually entering the same keystrokes works as expected, with and without numlock enabled.

  1. Did you try to “insert” some delay between the keystrokes?

Just gave that a try and seeing the same results. Even calling a single sendKeyStroke("Up") is showing a '8' character.

8

@bryan I’m passing it to our QA and i will update. thanks

11

Just an update: it’s on the R&D backlog. once they will done with it, i will update you here.
Thanks for your patience.

12

update: ETA for the fix is OW client version v141.

Thanks.

13

Thanks for the update. I’ll check it out in v141 when I can.

14

@bryan hi. can you please check the fix and let us know, so we will be able to close this ticket?

15

Hey, sorry for the delay. I have just retested on v. 0.141.79.22 (Developers) and am still seeing the issue consistently.

I’ve attached a video demonstrating the problem. In the video, we press our “Auto-Fill” button which sends a series of consecutive calls to sendKeyStrokes. First button press I have num lock disabled (as you can see from the on-screen keyboard), and the key strokes work as expected. Second attempt is with num lock enabled, and you’ll notice that the input is not the same as with num lock off.

keystroke-issue.zip (1.1 MB)

16

@bryan I can see the issue on your Video. But unfortunately, i can’t reproduce it on v141.
Note that I am manually calling the sendKeyStroke function from the console, not using a code that sends multiple chars rapidly.

Can you please send me the app that you are testing it with, or send me the particular code block, that I can run from my console and test and reproduce it?

17

I’ve attached a modified version of the Rocket League sample event app to help reproduce the issue. Attached zip contains the following contents:

  • ow-version.png (screenshot of my current OW version, showing latest on Developers)
  • sendKeyStroke-numlock-disabled.mp4 (video showing numlock disabled and the expected results when pressing the demo button)
  • sendKeyStroke-numlock-enabled.mp4 (video showing numlock enabled and the results are not as expected)
  • rocket-league-events-sample-app (modified events simulator app to include a child window with a demo button to test)

Please follow these reproduction steps with the modified events simulator app:

  1. Prepare the test by opening the modified events simulator app, Rocket League, and the child window. The child window can be opened by pressing tab while in game.
  2. Navigate in-game to an input box, eg. pressing Play -> Private Match -> Join Private Match. Each attached video is on the Join Private Match screen.
  3. Click within the Name input box so set the focus. You should see a blinking cursor in the input box.
  4. Ensure that numlock is disabled. This can be confirmed by using the Windows on-screen keyboard.
  5. Press the sendKeyStroke demo button in the child window. Notice that the input box should now contain “ABC”. You can press the button multiple times and the input box contents should be replaced each time with “ABC”.
  6. Change numlock to be enabled using the on-screen keyboard.
  7. Repeat step 5 and notice that the input box shows “7.ABC” unexpectedly.

sendKeyStroke-issue.zip (774.7 KB)

18

@bryan thanks for all the info and sorry about the inconvenience.
I can see the issue. We will fix it and I will update you once it done.

Thanks.

21

An update: I raised the issue to the R&D again.

We will fix the numlock issue with INS, HOME, PG UP, PG DN, DEL, END - that should be work the same with num lock on/off.

In general we don’t’ want to allow a “batch” insert that can be used for cheating, so currently we will not implement a feature that allow to send array of chars.

Note that currently we are on a local holiday + covid-19 situation, so the fix might take some time. I will keep you updated.

Thanks.

22

@bryan I want to do a follow-up here:

  • Are they any updates since you created the ticket? Is it still relevant?
  • We released a long time ago some fix. But I don’t have any validation that it’s working as expected for you or not. Please update.
  • If it’s still relevant and reproducible: did you find any workaround till now? what is the priority for you and what is the impact on your app. I want to prioritize it better.

Thank you!

24

Thanks for the follow up. I don’t have any new information or workarounds since the last comment I added. But the issue has become less relevant for us since that comment, so feel free to close this issue as needed. We can open a new ticket if have more issues with this in the future.