Pasted text in the terminal is always highlighted and selected

Status changed to 'Confirmed' because the bug affects multiple users.

the issue is similar to bug #1925823 and downgrading bash to the 20.10 deb workarounds it

Ubuntu 21.04 uses the following vte packages:

    libvte-2.91-0, version 0.62.3-1ubuntu1
    libvte-2.91-common, version 0.62.3-1ubuntu1
    gir1.2-vte-2.91, version 0.62.3-1ubuntu1

Ubuntu 20.04 uses the following vte packages:
    libvte-2.91-0, version 0.60.1-1ubuntu1
    libvte-2.91-common, version 0.60.1-1ubuntu1
    gir1.2-vte-2.91, version 0.60.1-1ubuntu1

In Ubuntu 21.04, when text is pasted into Gnome Terminal, the text is always highlighted.

- It appears as if the text is selected, but it is only highlighted.
- If you right-click on this highlighted text, the "Copy" option is actually disabled.
- Clicking in the terminal or clicking on the highlighted text does not un-highlight the text.
- The only way to un-highlight the pasted text is to type a key.
- If you try to select the highlighted text by clicking and dragging the mouse pointer, the text color actually inverts, and the text looks like it is not selected, when it in fact is selected. enter image description here

This confusing behavior is not present in Ubuntu 20.04.

- In Ubuntu 20.04, when text is pasted into Gnome Terminal, the text is not highlighted.
- Then, selecting the text highlights it, as expected.

This is not an issue with the terminals, this is a new feature of bash-5.1. Search for the word "highlight" at https://lists.gnu.org/archive/html/info-gnu/2020-12/msg00003.html .

---

This could not theoretically be a bug in gnome-terminal/vte. Terminals don't directly paint a letter as a consequence of the user pressing that letter, or pasting something.

I'm certain you can think of plenty of cases where pressing a certain letter does not cause that letter to be painted on the canvas, but some other action (larger repaints), or perhaps nothing at all.

When you press a letter, or paste some text, it is forwarded towards the kernel over the tty line, but is not displayed. The kernel then might handle it itself, or forward further towards some application (e.g. bash in this case).

Then that application may or may not decide to paint something. Whatever it decides to paint may or may not be the same as the typed letter or pasted text. But even if it's the same, the terminal has no way of making this connection. "The user pressed the letter X, I've forwarded it, 100 milliseconds later I received a letter X to be painted, it must be the «same» X" -- it cannot work like this.

What happens in this particular case is that you paste "foo", and in response bash instructs the terminal to print "foo" in inverse colors. The terminal does what it must do: obeys this instuction (without having the slightest idea that it's related to the paste).

---

Two more things to mention to complete the picture:

There is a so-called "bracketed paste mode", where special markers are inserted at the beginning and end of pasted data. This is how applications (bash in this case) can distinguish it from data typed by the user, without relying on timing heuristics.

Also, some terminals have a legacy "local echo" mode where pressed keys immediately appear on the screen. I'm fairly certain it's not used anywhere nowadays. Most terminals don't support it, and VTE removed it in version 0.60, see https://gitlab.gnome.org/GNOME/vte/-/issues/69 .

@Egmont,

You mean it will always be like this going forward?

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Is this the feature you are referring to?...

f. New active mark and face feature: when enabled, it will highlight the text
   inserted by a bracketed paste (the `active region') and the text found by
   incremental and non-incremental history searches. This is tied to bracketed
   paste and can be disabled by turning off bracketed paste.

..or, is it this one?...

h. Bracketed paste mode is enabled by default.

If so, it looks like this "feature" can be disabled. How?

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

I find there is an inconsistency with this new approach:
If you've just pasted text, then highlight the text, the text looks unhighlighted.
This is visually confusing.

Perhaps this is an unintended consequence that needs remediation?

> You mean it will always be like this going forward?

I don't know. This was a change in the default shell "bash". I'm not involved in bash's development, nor in Ubuntu's. I don't know what their plans are. I don't know if this feature can be disabled in bash (but I know that it's bash's documentation to consult). I don't know if Ubuntu plans to disable it by default.

> Is this the feature you are referring to?...
> ..or, is it this one?...

I'm not aware of the exact details of bash's change, and I haven't tried bash-5.1 yet. Both of these look relevant, probably one of them is exactly this one.

> I find there is an inconsistency with this new approach:
> If you've just pasted text, then highlight the text, the text looks
> unhighlighted.
> This is visually confusing.

This is a good observation. gnome-terminal by default inverts the colors of each cell (I mean: swaps the background and the foreground color) when you highlight with the mouse. Now, if an application also does this (like bash now when pasting, or that one row of "top", etc.), and then you highlight with the mouse, these two operations cancel out each other and you're back to your regular colors. Both components do something that's reasonable on its own, yet the two don't work together nicely.

One possible workaround is to configure your terminal to use some fixed colors for highlighting. I, for one, have configured gnome-terminal to use the same orange-ish background that Ubuntu uses anywhere else in GTK when highlighting text. You can configure it in profile settings -> colors, or emit the OSC 17 & 19 escape sequences to achieve the same effect, e.g. «echo -ne '\e]17;#f18458\e\\'». Presumably most other terminal emulators also support this feature. This might even be something for Ubuntu to consider doing globally for all the users by default.

Alternatively, you should be able to disable this feature of bash, or configure it to use different colors rather than inverse video. I don't know if these possibilities are implemented in bash, if not then you might need to patch its source or its the developers to add such features.

...patch its source or ask its developers...

> h. Bracketed paste mode is enabled by default.
> If so, it looks like this "feature" can be disabled. How?

The way to disable bracketed paste mode is presumably to place this in .inputrc:
set enable-bracketed-paste off

But DON'T do this! Bracketed paste mode is an important safety measure against malicious or accidental pastes that contain embedded newlines. See https://thejh.net/misc/website-terminal-copy-paste .

What you should be looking for is to preserve bracketed paste mode, yet revert to no highlighting, or customize the highlighting colors. I don't know how to do that because I haven't studied this new bash "feature" yet. If you look it up and find it, please post the answer here :)

This bug has been marked as invalid for gnome-terminal because it is a feature of bash shell.

However, should we mark gnome-terminal as impacted?...

I see the benefit to the change in bash from a security perspective, so perhaps gnome-terminal needs to adapt to this new feature.

Specifically, I think this behavior could be confusing to users:

  > If you try to select the highlighted text by clicking
  > and dragging the mouse pointer, the text color actually
  > inverts, and the text looks like it is not selected,
  > when it in fact is selected.

For example, @Egmont Koblinger suggested changing the high-light color in the terminal, so it does not match the "bracketed paste" color. This can be done through the color profile for gnome-terminal. This is one option, but it may have implications for accessibility (people who can not distinguish different colors due to color-blindness).

There may also be other things that gnome-terminal cold do to adapt to this change.

Therefore, may be we should leave gnome-terminal as impacted for now, so a good solution can be devised?

> I see the benefit to the change in bash from a security perspective, so
> perhaps gnome-terminal needs to adapt to this new feature.

You missed the possibility of keeping bracketed paste mode (the functionality) enabled (as I, for one, have had it enabled ever since bash added this feature, which was like version 4.3 or 4.4 or so), but configuring (patching?) bash not to use inverse colors for pasted text. Use regular colors as it used to do, or some actual coloring (e.g. magenta), or underlining etc.

> This is one option, but it may have implications for accessibility

If it's good enough for text highlighting in all GTK apps, including the Firefox browser, then I doubt there would suddenly be a11y considerations arising in the terminal. But of course I might be missing something.

> There may also be other things that gnome-terminal cold do to adapt to
> this change.

I can't think of any other easy way. I mean, for example Terminology uses fancy diagonal shading and stronger contour for the highlighted area, but I highly doubt gnome-terminal (vte) would do anything similar any time soon; especially if GTK doesn't have such a feature either.

Also don't forget that presumably about a dozen other terminal emulators suffer from the same problem. If you choose to adjust terminals to bash, rather than the other way around, you'll have to do it with many-many terminals. I don't believe it's the preferred approach.

Ubuntu MATE 21.10 impish will be affected by this bug if no additional measures will be taken. Please do something.

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1926256

Still happens on Jammy. Should be fixed before final release.

The temporary workaround is

echo "set enable-bracketed-paste Off" > ~/.inputrc

For better user experience this file should be placed into `/etc/shel` on the installation stage. So I'll mark base-files package as affected.

The default inputrc comes from readline-common; nothing to do with base-files.

Still a problem for Ubuntu MATE 22.04 LTS. Please fix it on distro level.

Still a problem for Ubuntu MATE 22.04 LTS. Please fix it on distro level.

Still a problem for Ubuntu MATE 22.04 LTS. Please fix it on distro level.
You break UX.

Freshly released bash-5.2 allows to disable the highlighting of pasted text (while keeping the "bracketed paste mode" functionality enabled), or even to define custom highlighting.

You need to place something like this in your .inputrc:

  set enable-active-region off

or

  set active-region-start-color "\e[42m" # change it to whatever you wish
  set active-region-end-color "\e[m"

EDIT: THIS IS THE WORKAROUND:
bind 'set enable-bracketed-paste off'

The proposed work around does NOT work for me. It could be due to the fact that it is over ssh?
I am sshing from 18.04 into 22.04.
Bash version on former is 4.4.20(1)-release
Bash version on latter is 5.1.16(1)-release

I CANNOT work with this 'feature' enabled. Please help. Thanks. (And this security argument makes no sense to me... why would I paste text into a terminal which I didn't select?)

Hi Warren,

You can rebuild the binaries.
I show how to do it here.
https://github.com/stdedos/stdedos/issues/1#issuecomment-1314438987

On Thu, 22 Jun 2023 at 22:07, Warren Andrews <email address hidden>
wrote:

> EDIT: THIS IS THE WORKAROUND:
> bind 'set enable-bracketed-paste off'
>
> The proposed work around does NOT work for me. It could be due to the fact
> that it is over ssh?
> I am sshing from 18.04 into 22.04.
> Bash version on former is 4.4.20(1)-release
> Bash version on latter is 5.1.16(1)-release
>
> I CANNOT work with this 'feature' enabled. Please help. Thanks. (And
> this security argument makes no sense to me... why would I paste text
> into a terminal which I didn't select?)
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1926256
>
> Title:
> Pasted text in the terminal is always highlighted and selected
>
> Status in bash package in Ubuntu:
> Invalid
> Status in gnome-terminal package in Ubuntu:
> Invalid
> Status in mate-terminal package in Ubuntu:
> Invalid
> Status in readline package in Ubuntu:
> Confirmed
> Status in vte2.91 package in Ubuntu:
> Invalid
>
> Bug description:
> Steps to reproduce:
> 1. Have Ubuntu 21.04 installed
> 2. Launch terminal
> 3a. Execute some command, select this command to copy it, then paste
> command
> 3b. Paste some command from clipboard to terminal
>
> Expected result:
> * pasted command is not highlighted and is not selected
>
> Actual result:
> * pasted command is selected and highlighted
>
> [[Workaround]]
>
> * On 22.04, add 'set enable-bracketed-paste off' to /etc/inputrc
> * Starting 22.10, add 'set enable-active-region off' to /etc/inputrc
>
> ProblemType: Bug
> DistroRelease: Ubuntu 21.04
> Package: mate-terminal 1.24.1-1
> ProcVersionSignature: Ubuntu 5.11.0-16.17-generic 5.11.12
> Uname: Linux 5.11.0-16-generic x86_64
> ApportVersion: 2.20.11-0ubuntu65
> Architecture: amd64
> CasperMD5CheckResult: pass
> CurrentDesktop: MATE
> Date: Tue Apr 27 09:43:56 2021
> InstallationDate: Installed on 2021-04-23 (3 days ago)
> InstallationMedia: Ubuntu-MATE 21.04 "Hirsute Hippo" - Release amd64
> (20210420)
> SourcePackage: mate-terminal
> UpgradeStatus: No upgrade log present (probably fresh install)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1926256/+subscriptions
>
>

> EDIT: THIS IS THE WORKAROUND:
> bind 'set enable-bracketed-paste off'

It's absolutely unclear to me what you're referring to here. You mention a workaround that wasn't mentioned earlier in this thread, the word "bind" first appears in your comment (so: where did you take it from?) then you say it doesn't work for you.

What do you do with this line? Do you execute it once, as a command? Before or after ssh'ing? Or execute in every terminal? Or place it in a file (which)? If you're looking for help, you should at least tell us step by step what you're doing.

(By the way, this is an issue tracking forum and not a user support one. User support questions should much rather go to sites like askubuntu.com or answers.launchpad.net. Your comment does not in any way help developers get closer to fixing the issue.)

> It could be due to the fact that it is over ssh?

Sure it could be. So, have you experimented with it, have you tried to perform the said action on both computers?

> I CANNOT work with this 'feature' enabled.

This sounds like an obvious exaggeration. You're crying wolf. I believe it annoys you, but it's sure untrue that you in all-caps "CANNOT" work due to this (especially more than 1 year after the release of this annoying behavior).

> And this security argument makes no sense to me... why would I paste text into a terminal which I didn't select?

Follow the link from comment 11 (that is: yes, it was already shown in this thread).

alainpannetier,

You show how to rebuild the terminal emulator widget (not exactly the version shipped by Ubuntu, without the patches and configurations shipped by Ubuntu), with one patch that is utterly irrelevant to this topic here.

I don't have the slightest idea how that could fix the truly unfortunate coloring.