Re: Broken arrow keys for browser access to proxmox and ESXi

So, I've run up a minimal patch to fixup the arrow key behaviour in
Firefox on NetBSD (included at bottom).

This patch works around the issue, but it is not an ideal fix:
- It is incomplete - it only fixes the arrow keys on NetBSD, not
potentially other mismapped keys
- It breaks the arrow key mapping for a NetBSD Firefox running
remotely on a Linux/FreeBSD display

However, I'd like to go ahead and commit it to www/firefox (and any
earlier versions where is is relevant) - it certainly makes my life a
lot easier using proxmox and ESXi web UI from Firefox on NetBSD

ryoon@ - would that be OK?

I'm going to open a NetBSD PR as I think a real fix may be to migrate
NetBSD to evdec scancodes

Thanks

David

$NetBSD$

// This file uses evdec scancodes for CODE_MAP_X11() entries, as implemented by
// modern Linux and FreeBSD.
// NetBSD does not use evdev scancodes, so we fixup at least arrow keys.
// This will cause a NetBSD firefox running remotely on a Linux/FreeBSD display
// to have the wrong arrow mappings, but that is a lesser issue.
// Behaviour can be easily seen on https://keyjs.dev/ - the correct case should
// have e.code showing Arrow{Up,Down,Left,Right}

--- widget/NativeKeyToDOMCodeName.h.orig        2025-12-17
16:39:00.000000000 +0000
+++ widget/NativeKeyToDOMCodeName.h
@@ -379,7 +379,9 @@ CODE_MAP_ANDROID(Tab, 0x000F)

 // IME keys
 CODE_MAP_WIN(Convert, 0x0079)
+#if ! defined(__NetBSD__)
 CODE_MAP_X11(Convert, 0x0064)
+#endif // ! __NetBSD__
 CODE_MAP_ANDROID(Convert, 0x005C)

 CODE_MAP_WIN(Lang1, 0x0072)  // for non-Korean layout
@@ -399,7 +401,9 @@ CODE_MAP_X11(KanaMode, 0x0065)
 CODE_MAP_ANDROID(KanaMode, 0x005D)

 CODE_MAP_WIN(NonConvert, 0x007B)
+#if ! defined(__NetBSD__)
 CODE_MAP_X11(NonConvert, 0x0066)
+#endif // ! __NetBSD__
 CODE_MAP_ANDROID(NonConvert, 0x005E)

 // Control pad section
@@ -439,22 +443,38 @@ CODE_MAP_ANDROID(PageUp, 0x0068)
 // Arrow pad section
 CODE_MAP_WIN(ArrowDown, 0xE050)
 CODE_MAP_MAC(ArrowDown, kVK_DownArrow)
+#if defined(__NetBSD__)
+CODE_MAP_X11(ArrowDown, 0x0068)
+#else
 CODE_MAP_X11(ArrowDown, 0x0074)
+#endif // __NetBSD__
 CODE_MAP_ANDROID(ArrowDown, 0x006C)

 CODE_MAP_WIN(ArrowLeft, 0xE04B)
 CODE_MAP_MAC(ArrowLeft, kVK_LeftArrow)
+#if defined(__NetBSD__)
+CODE_MAP_X11(ArrowLeft, 0x0064)
+#else
 CODE_MAP_X11(ArrowLeft, 0x0071)
+#endif // __NetBSD__
 CODE_MAP_ANDROID(ArrowLeft, 0x0069)

 CODE_MAP_WIN(ArrowRight, 0xE04D)
 CODE_MAP_MAC(ArrowRight, kVK_RightArrow)
+#if defined(__NetBSD__)
+CODE_MAP_X11(ArrowRight, 0x0066)
+#else
 CODE_MAP_X11(ArrowRight, 0x0072)
+#endif // __NetBSD__
 CODE_MAP_ANDROID(ArrowRight, 0x006A)

 CODE_MAP_WIN(ArrowUp, 0xE048)
 CODE_MAP_MAC(ArrowUp, kVK_UpArrow)
+#if defined(__NetBSD__)
+CODE_MAP_X11(ArrowUp, 0x0062)
+#else
 CODE_MAP_X11(ArrowUp, 0x006F)
+#endif // __NetBSD__
 CODE_MAP_ANDROID(ArrowUp, 0x0067)

 // Numpad section
@@ -536,7 +556,9 @@ CODE_MAP_ANDROID(NumpadDivide, 0x0062)
 CODE_MAP_WIN(NumpadEnter, 0xE01C)
 CODE_MAP_MAC(NumpadEnter, kVK_ANSI_KeypadEnter)
 CODE_MAP_MAC(NumpadEnter, kVK_Powerbook_KeypadEnter)
+#if ! defined(__NetBSD__)
 CODE_MAP_X11(NumpadEnter, 0x0068)
+#endif // ! __NetBSD__
 CODE_MAP_ANDROID(NumpadEnter, 0x0060)

 CODE_MAP_WIN(NumpadEqual, 0x0059)



On Sun, 4 Jan 2026 at 09:26, RVP <[email protected]> wrote:
>
> On Sat, 3 Jan 2026, David Brownlee wrote:
>
> > More information.
> >
> > - Disabling wayland in gtk3 and rebuilding all packages does not
> > resolve the issue
> >
>
> Yeah, that wasn't it. I think what's happening is, actually, this:
>
> On NetBSD (recent-ish -HEAD), and, also its close sister, OpenBSD-7.7:
>
> ```
> $ setxkbmap -print
> xkb_keymap {
>         xkb_keycodes  { include "xfree86+aliases(qwerty)"       };
>         xkb_types     { include "complete"      };
>         xkb_compat    { include "complete"      };
>         xkb_symbols   { include "pc+us+ctrl(swapcaps)+terminate(ctrl_alt_bksp)" };
>         xkb_geometry  { include "pc(pc104)"     };
> };
>
> $ fgrep -m1 DOWN /usr/X11R7/lib/X11/xkb/keycodes/xfree86
>      <DOWN> = 104;
>
> $ xev -event keyboard
> [...]
> KeyPress event, serial 28, synthetic NO, window 0x1600001,
>      root 0x50e, subw 0x0, time 103222, (89,89), root:(960,600),
>      state 0x0, keycode 104 (keysym 0xff54, Down), same_screen YES,
>      XLookupString gives 0 bytes:
>      XmbLookupString gives 0 bytes:
>      XFilterEvent returns: False
> [...]
>
> $
> ```
>
> Note that the keycode for ArrowDown is 104 (0x68).
>
> But, on Linux (Ubuntu 24.04.3) and FreeBSD-14.3 both of which use evdev:
>
> ```
> $ setxkbmap -print
> xkb_keymap {
>         xkb_keycodes  { include "evdev+aliases(qwerty)" };
>         xkb_types     { include "complete"      };
>         xkb_compat    { include "complete"      };
>         xkb_symbols   { include "pc+us+inet(evdev)+ctrl(swapcaps)+terminate(ctrl_alt_bksp)"     };
>         xkb_geometry  { include "pc(pc104)"     };
> };
>
> $ fgrep -m1 DOWN /usr/X11R7/lib/X11/xkb/keycodes/evdev  # checking on NetBSD here
>         <DOWN> = 116;
>
> $ xev -event keyboard
> [...]
> KeyPress event, serial 28, synthetic NO, window 0x1400001,
>      root 0x4b2, subw 0x1400002, time 12865061, (21,19), root:(234,130),
>      state 0x0, keycode 116 (keysym 0xff54, Down), same_screen YES,
>      XLookupString gives 0 bytes:
>      XmbLookupString gives 0 bytes:
>      XFilterEvent returns: False
> [...]
>
> $
> ```
>
> And, what evdev keycode is 104 (ie. ArrowDown in wscons)?
> ```
> $ fgrep 104 /usr/X11R7/lib/X11/xkb/keycodes/evdev
>         <KPEN> = 104;
>
> $
> ```
>
> It's KPEN (KeyPad Enter)--QED. And, in the Pale Moon UXP sources:
>
> https://repo.palemoon.org/MoonchildProductions/UXP/src/branch/master/widget/NativeKeyToDOMCodeName.h#L356
>
> we see (hex value):
>
> ```
> CODE_MAP_X11(ArrowDown,                 0x0074)
> ```
>
> which matches (only) the evdev scancode as stated here:
>
> https://developer.mozilla.org/en-US/docs/Web/API/UI_Events/Keyboard_event_code_values#code_values_on_linux_x11
>
>
> So, it's a "scancode" mismatch--a Linuxism, ultimately.
>
> Fix?
>
> 1. Patching the browser source(s) would be one way. (I only checked the
> Pale Moon sources--Firefox was 600 MB+; don't even want to know how large
> Chrome is!) You can try Pale Moon immediately, then use that as a guide
> to figure out where the Firefox equilavent is. Chrome, I leave to someone
> else :).
>
> 2. Make the kernel generate evdev-compatible scancodes (then use the
> evdev keycodes in Xorg) if requested (`wsconsctl -w encoding=us.evdev`)?
>
> HTH,
>
> -RVP