AmiBrowser & broken JavaScript keyboard events

[mike-taws]

Hi there

First of all, kudos for AmiBrowser, that's really a neat trick with the backend rendering and all. Very well done!
I was surprised in seeing how well my TAWS project (https://taws.ch) runs on it. After some more intense testing, I noticed something, though: keyboard control with the simulated HippoPlayer doesn't seem to work properly and now I finally triggered it down to why that is:

It seems that JavaScript keyboard events are... well... behaving strange, to put it mildly. Here's a test page and you'll notice the wild things it reports with AmiBrowser when comparing to any other browsers:
https://mrupp.ch/Test/KeyTest.htm

Most keys report a correct "key", but some faulty "code". "Enter" key reports "code" as F2 or even F18 on the "onkeyup" event. If you try a non u.s. keyboard layout (like german) things get mixed up even more: some events still report a "z" to be a "y", but "onkeypress" reports a correct "keyChar" nevertheless.

This has been tested with AmiBrowser 46.37 (13.02.26).

Keep up the good work and I hope that my little test page helps in tracking this down and fixing it.

Cheers,
Michael

[broadblues]

I've run a few tests, using https://en.key-test.ru/ and it looks like the key down value is wrong. This is masked by the fact t most things respond to key up. I'll look into it, thanks for the report.

[broadblues]

Some more testing between your test page and the other more graphic one I've found reveals that this is down to passing through the native keycode as is.

I had a note in the code that this may be the wrong thing to do :-)

The curious thing is that the unmodified raw key worked up key up (on the key test ru page at least) I'm now thinking tt that i because it was out of range, so the code was falling back to the interpreted value, which passed separately.

The irony here  is that taws is probably converting this keycode back to an amiga rawkey code when it already is.

I've tried converting to linux input code, as it's running on linux backend CEF might expect that, and I have a convenient premade table for that for the linux builds of my MKShare tool,  but it appears not. That gives worse results!

[broadblues]

This should be largely fixed in the ext update.

[mike-taws]

This should be largely fixed in the ext update.

Hey, this is excellent news!
I have now updated to the lastest version of AmiBrowser (46.38) and did some more testing. Here are the results:

• NumPad9 reports as NumPad8
• NumPad8 reports as ScrollLock
• F11 reports as Backslash
• INSERT reports as MetaLeft
• HOME reports as MetaRight
• END doesn't report at all
• PageUp reports as ScrollLock, too
• PageDown doesn't report at all
• ScrollLock doesn't report at all
• PRINT doesn't report at all
• CapsLock doesn't seem to invoke "OnKeyDown" and "OnKeyUp" but with every keypress, it switches between the two (while "OnKeyPress" being with "OnKeyDown")
• ESC closes the browser, even if event.preventDefault() is called (but I guess that's a bit of another issue)

When using a german keymap, some values for Z and Y are still reported switched, but not all. Let's take key Y (between T and U) as an example: It is correct, that "Code" always reports "KeyY", no matter the keymap of the OS, and this works correctly. But for "KeyChar" and "Key", all events should report a "Z" for a german keymap. Currently this works only for "Key" value of event "OnKeyPress" correctly, all other events still report a "Y".

I tested with two different keyboards, just to be sure. Both gave the same results.
Just as a sidenote: TAWS doesn't convert any keycodes back or forth. As this is not emulation but "simply" (haha) a web page.

Keep up the good work, just a few more little glitches to go!

Cheers,
Michael