Keyboard "code" value is being overwritten to "Hyper"

Issues - Platform and API
, , ,
#1

Scenario:

As a devloper, I modified my manifest to enable showing my app both in desktop mode and in game.

I then listened to the default document keyDown event, and looked at its values

expected result:

Clicked on “A key”, got event with code “KeyA”

image

actual result:

Clicked on “A key”, got event with code “”

image
image1264×50 13.2 KB

how to reproduce?

  1. open an overwolf app’s devtools (one that is not desktop only)

  2. run the following command in the devtools terminal:

document.addEventListener(“keydown”,e=>console.log(“Event Key”,e.code,e))

#2

Update:
the actual result now is:

Clicked on “A key”, got event with code “Hyper” (it’s the same for all keys)

image

#3

@shir.brass what exactly are you trying to achieve here. I didn’t understand the relation to the desktop or in-game windows that you mentioned above.

In addition, why don’t you use the overwolf.games.inputTracking.onKeyDown event?

#4

I’m allowing my users to use keys to navigate in videos (e.g: left arrow to go backward in video or right arrow to go forward in video)

we use the window’s API in order to get the user’s input for these actions (it has nothing to do with the game, so overwolf.games.inputTracking won’t be helpful)

while trying to reuse a desktop window as an in-game window, I’ve found a discrepancy between desktop and in-game in window functionality (again, native window object, nothing special here)

#5

@shir.brass from my tests, I can see that it always returns code: Hyper, for desktop and in-game windows. I don’t know the reason. I can forward it to R&D.

But the question is - isn’t the key is not enough for you?

#6

“is it enough” is a tricky quesiton…
is it enough for implementing my solution? it could be, yes.
is it enough so OW will support the standard? I don’t think so

my expectation is that a window’s KeyboardEvent would work like a KeyboardEvent, that’s all :slight_smile:

#7

@shir.brass yes, of course, my meaning was more like - do you have a workaround for now… as fixing it probably will be in low priority and will take some time.

I believe that our API should resolve it. It’s just a matter of priorities.

#8

we indeed have a workaround (which is using one of the other fields of the event)

as long as the other fields remain stable, I can live with this bug for now :slight_smile:

#9

@shir.brass I created a bug for the R&D (low priority though).

Closing the ticket. Thanks.