Inconsistent behavior of SendKeyEvent on Win vs Linux

[akaltar]

I am using the latest CEF3 binary release from the spotify site.

I am using CEF3 for offscreen rendering. The window creation is handled by a cross-platform library, that sends consistent key events on all platforms.

In what format should I fill the CefKeyEvent struct to make it behave consistently on all platforms?

Currently I tried mapping everything to windows key codes, and sending text as utf16 characters in the char member. This works on Linux, but on window it seems that the character code is ignored even though I set the event type as KEYEVENT_CHAR.

[Czarek]

Sending windows key codes on Linux is what I do as well. Are you setting both "character" and "unmodified_character"? Are you sending both RAWKEYDOWN and CHAR events?

[akaltar]

I am sending KEYDOWN / KEYUP and CHAR events only.

If I get text input from the library I am using I send CHAR events, otherwise KEYDOWN / KEYUP.

I am only filling the windows_key_code, character, modifiers fields in the struct.

What else should I fill(Hopefully without having to use separate lookup tables for win/linux?
Or just what do they mean? The documentation is very sparse about this :/

[Czarek]

Implement CefKeyboardHandler and listen to keyboard events. See which events and what values are sent for given key presses. Do this in a non-OSR example.

[akaltar]

I have delved into the source code to see how things are handled. It seems there is no solution to my problem. I would have to map a UTF8 character back to a Windows keycode AND a native keycode, which depends on locale too.

The keyboard input system currently employed is horrible to be used with OSR and cross-platform libraries that abstract away the operating system.

The saddest thing in it all is that CEF abstracts away the OS too, so it could use a uniform input system.

I wish I had the knowledge to make the necessary changes to add an option for sending UTF8 data on all platforms, but I don't. (Especially since unit testing is required).

Anyways thanks for your help.

[magreenblatt]

There is an issue for this: https://bitbucket.org/chromiumembedded/ ... m-specific

[akaltar]

I managed to solve this partially, by using UTF16 character codes for windows_key_code and character, unmodified character values.(and of course set modifiers properly).

This is a nice simple work-around, but still prints some warning about character codes occasionally.

If there would be a change, UTF8 string input would be good. As many frameworks handle IME on their own, resulting in a UTF8 string(most commonly). So if we could just add that as a "pure-text" input and have a separate event type for keystrokes, that would be great. I don't know chromium limitations, so sorry if what I am supposing is not possible.