Persistent resize dialog when scrollbar is present

[gpanders]

Issue Description

When the scrollbar is visible, the resize dialog constantly reappears (see video).

Screencast.from.2025-12-05.12-16-24.webm

Disabling the scroll bar (e.g. clearing the screen, going to the alt screen, or setting scrollbar = never) makes the dialog go away.

Expected Behavior

There should not be a resize dialog when the window is not being resized.

Actual Behavior

The resize dialog appears when the window is not resized and persistently reappears.

Reproduction Steps

1. Open Ghostty
2. Create enough scrollback to make the scrollbar appear
3. Observe the resize dialog

Ghostty Logs

No response

Ghostty Version

The commit hash is stripped for some reason, but this is using the latest tip release as of this writing (08c9661).

Ghostty 1.3.0-dev+0000000

Version
  - version: 1.3.0-dev+0000000
  - channel: tip
Build Config
  - Zig version   : 0.15.2
  - build mode    : .ReleaseFast
  - app runtime   : .gtk
  - font engine   : .fontconfig_freetype
  - renderer      : renderer.generic.Renderer(renderer.OpenGL)
  - libxev        : io_uring
  - kernel version: 6.14.0-1015-oem
  - desktop env   : gnome
  - GTK version   :
    build         : 4.14.5
    runtime       : 4.14.5
  - libadwaita    : enabled
    build         : 1.5.0
    runtime       : 1.5.0
  - libX11        : enabled
  - libwayland    : enabled

OS Version Information

Ubuntu 24.04.3

(Linux only) Display Server

Wayland

(Linux only) Desktop Environment/Window Manager

GNOME 46.0

Minimal Ghostty Configuration

# Reproduces with default configuration

Additional Relevant Configuration

No response

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]

I've not seen this problem on sway both in tiling or floating mode, I also tried client side decor nothing there either
on commit 09f7e38b45ba9ad325c587f4e8acd66b8de8e9d5

I also just rebuilt the latest commit 08c9661683edc1e9e63d8e6abd469a68faaee575 and dont see the issue

[hakonhagland]

I can confirm this issue and the proposed workaround.

Environment

• Ubuntu 25.10, GNOME 47.4, Wayland
• Ghostty 1.3.0-main (tip)
• GTK 4.20.1

Root Cause

The issue is triggered by the GNOME setting:

gsettings get org.gnome.desktop.interface overlay-scrolling
# returns: false

When overlay-scrolling is false (traditional/non-overlay scrollbars), the resize overlay gets stuck when the scrollbar appears.

Workaround

gsettings set org.gnome.desktop.interface overlay-scrolling true

After changing this setting, the resize overlay behaves correctly and fades away as expected.

Related

I discovered this while investigating a separate issue where middle-click paste was also broken with non-overlay scrollbars. Both issues share the same root cause.

See: #10616

The proposed patch in this thread (tracking size changes to prevent feedback loops) would fix the resize overlay issue for users who prefer traditional scrollbars.

Note: Two Independent Issues

The overlay-scrolling false setting causes two separate issues that require independent fixes:

Issue	Symptom	Fix
This discussion (#9820)	Resize overlay stuck	Track size changes, only call callbacks when dimensions change
#10616 / PR #10614	Middle-click paste broken	Capture middle-click at ScrolledWindow level, forward to Surface

The resize fix (this thread) addresses callback logic, while the middle-click fix addresses GTK event propagation. Users who prefer traditional scrollbars would need both fixes for full functionality.

[ploxiln]

I didn't realize GTK could have non-overlay scrollbars (or, don't remember). But this sounds plausible. On macOS we fully forced the GUI system to disable non-overlay scrollbars because making them work without text reflow in the terminal was very hard and error-prone.

It's an easy enough setting to access in the macOS and gnome/cinnamon desktop appearance settings, and I always disable overlay scrollbars, because I don't want the scrollbar to fade-out and disappear, I want to see it (and not have it cover content). In other terminals (urxvt, gnome-terminal, Terminal.app), the scrollbar is shown from the start in an empty terminal, avoiding reflow when content overflows initial height.

It's possible that a number of people who were waiting for ghostty to get scrollbars, were the same people who disable overlay-scrollbars so they actually get real scrollbars :)

[DreitTheDragon]

Just here to confirm that mentioned workaround seems to work 👍

ArchLinux (updated few days ago)
Sway 1.11
GTK 4.20.3
Ghostty 1.3.1

[skoozbox]

Using X11 the workaround doesn't seem to work - size popup stuck and no middle mouse button response.
(I tested the workaround on Wayland and it was fine)

Using Fedora 43 with Cinnamon
ghostty-1.3.1-1.fc43.x86_64
gtk4-4.20.3-1.fc43.x86_64

~$ gsettings get org.gnome.desktop.interface overlay-scrolling
true

[jcollie]

A fix was recently merged, so you'll need to build from source to see if the fix worked for you.

[Hardy7cc]

I also ran across this one and I tried to investigate this a little more.

As far as I can tell the root cause of this is, that when the "resize_overlay" widget is hidden with setVisible(0) this emits a resize event. I'm no expert with GTK so no idea why, but this event seems to bubble up until it triggers our glareaReszie callback. Therefore within this callback we schedule another "resize_overlay" round which will show our resize-overlay-widget and start a loop of persistently showing it.

So I see following two issues:

• The hiding of the resize_overlay triggers a signal loop.
  • For some reason beyond my understanding if the global option org.gnome.desktop.interface overlay-scrolling is set to true this signal loop is broken and hiding the resize_overlay widget won't trigger another resize event.
  • This signal loop can also be broken with a patch similar to the one suggested by @alexkuz in the comments above. Basically only call self.resizeOverlaySchedule if the size has actually changed.
• The resize_overlay always intervenes with the mouse action (see Middle-click paste does not work when GTK scrollbar is enabled #10616)
  • To me this seems to be a secondary problem. i.e. in normal operation the resize_overlay is hidden before users execute another mouse action.
  • Maybe someone with enough GTK understanding can tell why the "reszie_overlay"-widget seems to swallow all mouse operations when it is visible. However I suppose it is okayish to ignore this one because the overlay is hidden fast enough and most won't hit this one.

I could PR a patch along the lines of the suggested one by alexkuz. This fixed this issue for me.
Note: There might be some other smart solution to convince GTK to not send the resize-signal in that specific case and therefore there would be no loop of events.

[tristan957]

Promoted to issue in #11970.