Pasted text in the terminal is always highlighted and selected

Bug #1926256 reported by Norbert
32
This bug affects 7 people
Affects Status Importance Assigned to Milestone
bash (Ubuntu)
Undecided
Unassigned
gnome-terminal (Ubuntu)
Undecided
Unassigned
mate-terminal (Ubuntu)
Undecided
Unassigned
vte2.91 (Ubuntu)
Undecided
Unassigned

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

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)

Revision history for this message
Norbert (nrbrtx) wrote :
Norbert (nrbrtx)
summary: - Pasted texted in the terminal is always highlighted and selected
+ Pasted text in the terminal is always highlighted and selected
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in gnome-terminal (Ubuntu):
status: New → Confirmed
Changed in mate-terminal (Ubuntu):
status: New → Confirmed
Changed in vte2.91 (Ubuntu):
status: New → Confirmed
Revision history for this message
Sebastien Bacher (seb128) wrote :

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

Changed in gnome-terminal (Ubuntu):
status: Confirmed → Invalid
Revision history for this message
PJSingh5000 (pjsingh5000) wrote :

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.

Norbert (nrbrtx)
Changed in bash (Ubuntu):
status: New → Confirmed
Revision history for this message
Egmont Koblinger (egmont-gmail) wrote :

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 .

Revision history for this message
PJSingh5000 (pjsingh5000) wrote :

@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?

Revision history for this message
Egmont Koblinger (egmont-gmail) wrote :

> 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.

Revision history for this message
Egmont Koblinger (egmont-gmail) wrote :

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

Revision history for this message
Egmont Koblinger (egmont-gmail) wrote :

> 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 :)

Revision history for this message
Cubic PPA (cubic-wizard) wrote :

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?

Revision history for this message
Egmont Koblinger (egmont-gmail) wrote :

> 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.

Norbert (nrbrtx)
tags: added: impish
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.