When arrows pushed, caret moves once

Brave Browser Desktop Support
,
1

Using the latest brave browser on linux debian, in the text input areas (search in google, brave browsers, chatgpt and so on) when pressing (and keep it pressed) the left or right arrows to move the caret in the text, it just moves once.

I have to tap multiple times the keyboard arrows to move the caret accordingly. Every other browsers (Firefox, chromium) on my system exhibit the expected behavior: have the caret moving up to the beginning/end of the input while the arrow is pressed.

Same for the delete key.

Is there a setting somewhere that I missed?

2

This may be an app specific setting on your Linux system – on my end I do not see this issue in Brave on macOS, Windows or Linux (Ubuntu).

Could be an issue with a specific extension installed in the browser which is also worth checking if you have any installed.

3

That’s strange.

Even Vivaldi works as expected. I deleted all the profiles, cache, config related to BraveSoftware. Barebones Brave with no extensions. No specific application settings for Brave registered anywhere.
No caret browsing enabled.

I run on Debian testing.

4

The discussion and illustrations at the following, may help / give you some ideas:

‘How can I turn Caret Browsing permanently ON by default for alll new windows?’

5

Ok guys, I went ahead and downloaded multiple versions of the browser.

The last functioning (as expected) stable version of the browser is 1.84.141

The first stable version fucking up is

So we definitely have something going on between V1.84 and v1.85 regarding the key strokes.

Please note: Chromium works just fine, as does Vivaldi.

6

Assuming that your issue is: You want Caret Browsing enabled

Reading and studying the information of several posts at the link that I provided:

‘How can I turn Caret Browsing permanently ON by default for alll new windows?’

might help you to discover how to get Caret Browsing enabled and enduring.

7

Ah, I get it: I don’t care about caret browsing (and don’t want it, either) it was just an info to make sure that this setting wasn’t interfering :slight_smile:

There was a change past Brave 1.84 that changed the behavior of the repeated left/right keystroke when the key is kept pressed. And this is this behavior I would like to restore. Maybe there is a deep/non obvious setting that made its way into the v1.85.

This is what I am after :wink:

8

@Joan1 Which version of Debian are you using and which graphical environment (Xorg v. Wayland, KDE v. GNOME?) are you using?

I’m using Debian unstable, Xorg, the i3 window manager and Brave 1.85.111 and I can scroll just fine by holding the arrow keys in the google.com search box.

9

Ok:

  • Linux, Debian testing,
  • Wayland.
  • Brave v1.85.111.
  • KDE 6.
  • Kernel: 6.17.9+deb14-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.17.9-1 (2025-11-26) x86_64 GNU/Linux
  • Nvidia graphics: Driver Version: 580.105.08 CUDA Version: 13.0.

Up to date system.
Thanks!

10

@Joan1

My guess would be, that Wayland + Brave (updated), given your setup (and settings?) is where the problem is.

11

Wayland + NVIDIA + GNOME on Ubuntu 24.04 works for me.

12

@Joan1 Just to rule this out, are you able to test with GNOME/Wayland on your machine?

13

Yes, I will test that out this morning and report

14

Switching to x11, the problem disappears.

So it’s clearly a wayland issue that happened in the v1.85 version.

Next: installing gnome and report again.
Really hope it will help to pinpoint the issue because I really don’t want to install that DE.

15

Ok, it’s a KDE issue. Gnome 49 + Wayland works perfectly fine. :slightly_smiling_face:

16

So it’s only broken in KDE+Wayland?

17

Yes correct!

  • Works fine on Gnome
  • Works fine on X11

Only KDE6 + Wayland from the v1.85 behaves in a weird fashion

18

I tested KDE5+Wayland on Ubuntu 24.04 and that works fine too. So it looks like it might be KDE6 specific.

19

:thinking:

I will download some nightly this morning between the two stable versions. Maybe there is a version that exhibits that behaviour and that will reduce the commits scope by a wide margin

20

Found out the culprit, that should really help to pinpoint the issue.

It’s starting with the 1.85.108 release, using chromium 143.

The release 1.85.107beta works perfectly fine and it uses chromium 142.

There is something with the underlying chromium setup between those two versions. Please note: it affects all upcoming versions after this.

:call_me_hand: