Middle-click paste does not work when GTK scrollbar is enabled

[hakonhagland]

Issue Description

Middle-click paste (primary selection paste) does not work when the GTK scrollbar feature is enabled. The GtkScrolledWindow intercepts middle-click events before they reach the terminal surface.

I investigated this issue and created a fix. See "Additional Relevant Configuration" for the full analysis and proposed solution.

Previously submitted as Issue #10613 and PR #10614 (closed per triage protocol).

Expected Behavior

Text from primary selection should be pasted into the terminal when middle-clicking, as it does when scrollbars are disabled (scrollbar = never).

Actual Behavior

Nothing happens when middle-clicking. The paste does not occur. The GtkScrolledWindow intercepts the middle-click event before it reaches the terminal Surface's GestureClick handler.

Reproduction Steps

1. Use Ghostty with scrollbars enabled (scrollbar = system in config, or default)
2. Select some text in another application to populate primary selection
3. Middle-click in Ghostty terminal to paste
4. Observe: Nothing happens - the paste does not occur
5. Set scrollbar = never in config and restart Ghostty
6. Middle-click again - paste now works

Ghostty Logs

No response

Ghostty Version

Ghostty 1.3.0-dev+6c0e02d

Version
  - version: 1.3.0-dev
  - channel: tip
Build Config
  - Zig version   : 0.15.2
  - build mode    : ReleaseFast
  - app runtime   : gtk

OS Version Information

Ubuntu 25.10

(Linux only) Display Server

Wayland

(Linux only) Desktop Environment/Window Manager

GNOME 47

Minimal Ghostty Configuration

scrollbar = system

Additional Relevant Configuration

Investigation and Fix

I built a debug version with logging in gcMouseDown() in src/apprt/gtk/class/surface.zig:

• With scrollbar = never: Handler receives middle-click, paste works
• With scrollbar = system: Handler never called, event intercepted by ScrolledWindow

Root Cause

The GtkScrolledWindow intercepts middle-click events before they propagate to the Surface's GestureClick handler. This is likely because GTK's kinetic scrolling uses middle-click for autoscroll.

Proposed Fix

1. Add a GestureClick with propagation-phase: capture to the ScrolledWindow
2. This intercepts middle-clicks before the ScrolledWindow can consume them
3. Forward the event to the Surface's mouse handler
4. Claim the gesture to prevent double-paste

Changed Files

src/apprt/gtk/ui/1.5/surface-scrolled-window.blp - Add GestureClick to ScrolledWindow
src/apprt/gtk/class/surface_scrolled_window.zig - Add callback handler
src/apprt/gtk/class/surface.zig - Add forwardMouseDown() public method

Full Implementation

Fork with fix: https://github.com/hakonhagland/ghostty/tree/fix-scrollbar-middle-click-paste
Closed PR with diff: #10614

I acknowledge that:

• I have reviewed the FAQ and confirm that my issue is NOT among them.
• I have searched the Ghostty repository (both open and closed Discussions and Issues) and confirm this is not a duplicate of an existing issue or discussion.
• I have checked the "Preview" tab on all text fields to ensure that everything looks right, and have wrapped all configuration and code in code blocks with a group of three backticks (```) on separate lines.

[rhodes-b]

works just fine for me with using sway without any changes on the latest commit. So there is something else beyond the ScrolledWindow intercepting the events

Ghostty 1.3.0-main+769fff5df

Version
  - version: 1.3.0-main+769fff5df
  - channel: tip
Build Config
  - Zig version   : 0.15.2
  - build mode    : .Debug
  - app runtime   : .gtk
  - font engine   : .fontconfig_freetype
  - renderer      : renderer.generic.Renderer(renderer.OpenGL)
  - libxev        : io_uring
  - kernel version: 6.12.60
  - desktop env   : other
  - GTK version   :
    build         : 4.20.3
    runtime       : 4.20.3
  - libadwaita    : enabled
    build         : 1.8.2
    runtime       : 1.8.2
  - libX11        : enabled
  - libwayland    : enabled

edit that wasnt the most recent commit I forgot to pull it down, testing the most recent it still works

Ghostty 1.3.0-main+6c0e02d11

Version
  - version: 1.3.0-main+6c0e02d11
  - channel: tip
Build Config
  - Zig version   : 0.15.2
  - build mode    : .Debug
  - app runtime   : .gtk
  - font engine   : .fontconfig_freetype
  - renderer      : renderer.generic.Renderer(renderer.OpenGL)
  - libxev        : io_uring
  - kernel version: 6.12.60
  - desktop env   : other
  - GTK version   :
    build         : 4.20.3
    runtime       : 4.20.3
  - libadwaita    : enabled
    build         : 1.8.2
    runtime       : 1.8.2
  - libX11        : enabled
  - libwayland    : enabled

[hakonhagland]

Thanks for testing! That's interesting - it suggests this might be GNOME-specific.

My environment:

• Desktop: GNOME 47.4 on Ubuntu 25.10
• Display server: Wayland
• GTK: 4.20.1
• libadwaita: 1.8.0

I can reliably reproduce the issue on my setup:

1. Fresh Ghostty window with scrollbar = system
2. Select text in another app
3. Middle-click in terminal → nothing happens
4. Change to scrollbar = never, restart → middle-click works

The debug build confirmed that gcMouseDown() is never called when scrollbars are enabled, but is called correctly when they're disabled.

Could you test on GNOME if you have access? It's possible GNOME's GTK configuration or compositor handles ScrolledWindow events differently than Sway.

If this is GNOME-specific, I'm happy to investigate further on my end. The fix I proposed (capturing middle-clicks at the ScrolledWindow level) works on my system and shouldn't affect other environments.

[rhodes-b]

I just tested the Gnome VM provided by ghostty and it works just fine there as well

https://github.com/ghostty-org/ghostty/blob/main/CONTRIBUTING.md#nix-virtual-machines
https://github.com/ghostty-org/ghostty/blob/main/nix/vm/wayland-gnome.nix

[hakonhagland]

Think I found the root cause! It's the GNOME setting:

  gsettings get org.gnome.desktop.interface overlay-scrolling                                                                                                 

• With overlay-scrolling=true (default): middle-click works fine
• With overlay-scrolling=false (traditional scrollbars): middle-click is intercepted by ScrolledWindow

I had overlay-scrolling=false. Changing it to true fixes the issue without any code changes.

So this affects users who disable overlay scrolling in GNOME. The fix I proposed in PR #10614 would restore middle-click for those users, but it's a niche case.

Thanks for helping narrow this down!

[mitchellh]

Thanks, I just vouched you so you can open PRs now, can you resubmit your PR with the fix? Thank you for following protocol. ❤️

[hakonhagland]

See also #9820 for a related issue.

[mitchellh]

!vouch