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

[broadblues]

```
    NumPad9 reports as NumPad8        -  SHOULD BE IN NEXT RELEASE FIXED REVERSED CODE order in table
    NumPad8 reports as ScrollLock        - FIXED ditto
...

```
    F11 reports as Backslash                  - my test in cefclient shows correct hardware code in table,
    INSERT reports as MetaLeft             - my test in cefclient shows correct hardware code in table,
    HOME reports as MetaRight             -  my test in cefclient shows correct hardware code in table,
    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
```

These are  more complex the codes in the table are correct based on the key events generated on the linux side, it may be there is some translation happening between the linux keyboard and the rawkey emitted inside the emulation.

My table originally mapped RawKeys (sent by MKShare from AmigaOS4) to linux uinput events, it's 99% accurate insofar as the correct key events occure on the linux side when an amigaos4 key is pressed. So I filled in the entries in reverse to create the newtranslation of rawkey to lowlevl hardware key.

I'll  have to add a extra debug layer to see what RawKey I get inside the AmiBench layer. Perhaps these spacial keys have been traslated by AmiBerry to look more like an amiga keyboard.

```
    CapsLock doesn't seem to invoke "OnKeyDown" and "OnKeyUp" but with every keypress, it switches between the two (while "OnKeyPress" being with "OnKeyDown")
```
I'll bet RawKey events are only being created on transitions of the key state here as it;s a locking key.. tempted to blame input device for that one (without hard evidence :-))

```
ESC closes the browser, even if event.preventDefault() is called (but I guess that's a bit of another issue)
```

This key is intercepted by MUI before it can be sent to the browser engine, it may r may not be possible to listen for that javascript call later on.

[broadblues]

OK added a extra layer of debug:

  END doesn't report at all

Doesn't generate a RawKey event at all so that will be why.

    PageUp reports as ScrollLock, too
    PageDown doesn't report at all

I have this the other way round PAGEDOWN generates RawKey 95 (ie it's mapped to scroll lock AKA known as HELP in amiga keyboard context on OS4 atleast) PAGEUP emits no event

    ScrollLock doesn't report at all

Doesn't emit a rawkey event.

    PRINT doesn't report at all

Also no RawKey event,


F11 Is mapped to RawKey 13 (backslash)

HOME and INSERT are mapped to 102 103 ie Left and Rght Amiga.


So these "errors"  the result of the default keyboard emulation.