`k` handled as tab key -- cycling through focus-able elements -- conflict with vimium

Browser Support Desktop Support
1

Description of the issue: Pressing k causes cycling through focus-able elements, as Tab does (or Shift-Tab in reverse). g cycles through images.

Testing on xkcd.com, example.com, search.brave.com, eff.org.

This occurs in private mode, with Vimium as the only extension active, and with Vimium disabled.

  • with Vimium (key bindings):
    • press j - move down a small increment with repeated key presses,
    • then press k - page scrolls up to the first focusable element, the focuses on a new element with each keypress
  • private window, Vimium disabled, no other extensions loaded:
    • j - does nothing - as expected
    • k - toggles in sequence through selectable elements. Some initial delay.

I’ve confirmed that my inputs are being recognized as the k key consistently, by running $ showkey in the background, noting keycode 37 press/keycode 37 release events for k, 36 for j, consistent between typing into terminal, browser URL bar, and while seeing unexpected web page scrolling behavior.

  • g - seems to cycle through images
  • k - cycles through (all?) clickable or focusable elements

How can this issue be reproduced?

  1. Load one of these test sites (some sites do add custom keypress-shortcut handlers). Optionally scroll down a bit first, e.g. <space>
  2. Try pressing k, notice same behavior as if tab-ing through the page (shift-tab to iterate in reverse). Try pressing g, notice iteration through images (usually many fewer focus targets available, 4 unique fixations on xkcd.com)

Expected result: g and k do nothing

Brave Version( check About Brave): 1.67.123 Chromium: 126.0.6478.126 (Official Build) (64-bit)

Additional Information: linux, KDE 6, neon. Using Wayland. Hopefully someone has insight if this is a wayland issue.

2

Excuse me, this misfeature seems to be present in upstream, at least Chrome, and likely Chromium.

I don’t know what I can do but raise an issue with the browser vendor :heart: .

3

ChatGPT helpfully suggests I may have had caret browsing turned on.

Caret browsing was off, I reproduce k’s behavior with Caret browsing turned on, or turned off again.

Wondering if chrome enabled caret browsing by default, and it’s passed through the chromium ecosystem. I don’t find anything in brave settings for /caret/, and /accessibility/ just returns the System >> Shortcuts /accessibility/ > Focus inactive popup for accessibility shortcut

  • brave://settings/?search=accessibility

Looks like I’ve had this version installed since 6-25, 1.67.123

/var/log/dpkg.log.1:2024-06-25 23:44:27 status half-installed brave-browser:amd64 1.67.119
/var/log/dpkg.log.1:2024-06-25 23:44:36 status unpacked brave-browser:amd64 1.67.123
/var/log/dpkg.log.1:2024-06-25 23:46:13 configure brave-browser:amd64 1.67.123 <none>
/var/log/dpkg.log.1:2024-06-25 23:46:13 status unpacked brave-browser:amd64 1.67.123
/var/log/dpkg.log.1:2024-06-25 23:46:13 status half-configured brave-browser:amd64 1.67.123
/var/log/dpkg.log.1:2024-06-25 23:46:14 status installed brave-browser:amd64 1.67.123
4

I installed orca screen reader on Linux, hoping to explore more configurable screen reading for passively consuming articles, from macOS. It was likely enabled on boot, and it took me some time to understand what caused unexpected reinterpretation of my keyboard inputs.

1 Like
5

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.