farblog

I recently refreshed a VM running Debian testing (Forky/Debian 14) and suddenly found that middle-click paste had stopped working… but only in Chrome?!

It turns out that it wasn’t actually only Chrome that was affected, and since this is likely something that I’ll run into again, I’m documenting it here for the next time I need it.

First, what am I talking about? X11 has the concept of both a modern clipboard (cut/copy/paste) and a separate “primary selection”¹ that’s updated whenever the user selects some text. Wayland (which I’m using) supports essentially the same idea.

This effectively gives you two separate clipboards, with one of them more ephemeral than the other. Middle-clicking with the mouse will usually paste from the primary selection, giving you both a ‘regular’ clipboard and a fast way to copy text from one place to another: just select it and middle-click to paste.

And this is the feature that had suddenly stopped working, but apparently only in Chrome; my terminal (foot) was working fine. Obviously, I initially assumed that Chrome was at fault, and it kind of was, but not in the way I expected.

I’ll spare you the trawling through /var/log/apt/history.log, and just explain what happened.

GNOME has for a while offered a setting to control whether middle-click paste is enabled, and Chrome, being approximately a GTK application on Linux, respects that setting.

Now, I’m not using GNOME (I use sway, the Wayland drop-in replacement for X11’s i3 window manager), but GTK applications will still read those GTK settings, even if I don’t have a convenient way to change them.

However, GNOME 50 decided to disable primary paste by default on the basis that it was confusing for new users, so the system default for this setting became false from gsettings-desktop-schemas version 50.0-1.

This affects all GTK applications, not just Chrome. However, at the time I wasn’t running any other GTK applications, so everything else continued to work just fine. (For example, foot is a non-GTK Wayland application, so it just uses Wayland’s native primary selection protocol, and doesn’t look at the GTK setting.)

The default value for this GTK setting comes from a compiled GSettings schema file². In this case the XML source is /usr/share/glib-2.0/schemas/org.gnome.desktop.interface.gschema.xml, which now looks like this:

<key name="gtk-enable-primary-paste" type="b">
  <default>false</default>
  <summary>Enable the primary paste selection</summary>
  <description>
    If true, gtk+ uses the primary paste selection, usually
    triggered by a middle mouse button click.
  </description>
</key>

(Previously, that default was true; that’s the change from gsettings-desktop-schemas.)

Debian does register a script with the user-session-migration package to re-enable this setting on a per-user basis after updating from an older version. That should run via /usr/bin/user-session-migration (which in turn is invoked by a systemd user unit that starts on GUI session startup).

However, firstly, that assumes you realise you need to log out and log in again after upgrading a package, and secondly, that systemd unit doesn’t appear to run at all on my Debian testing VM³.

In any case, that upgrade script also won’t help when I install from scratch (at which point I will definitely have forgotten where this setting is located!).

How to fix this, then? Well, for an upgrade, it is possible that running /usr/bin/user-session-migration might just work, so you could try that first.

Otherwise – and for new installs – changing the setting locally (which is all that script is doing) is the easiest way to revert to the older behaviour. Simply run:

$ gsettings set \
  org.gnome.desktop.interface gtk-enable-primary-paste true

or equivalently (if the gsettings binary from libglib2.0-bin is not installed, which it very well might not be):

$ dconf write \
  /org/gnome/desktop/interface/gtk-enable-primary-paste true

This updates ~/.config/dconf/user, and takes effect immediately (in Chrome, at least).

It’s slightly annoying that a default change in a desktop environment I’m not using was responsible for breaking functionality in a browser I am, but at least now I’ll know where to look the next time I need to understand this.