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!