Reported in https://github.com/ghostty-org/ghostty/discussions/14064
I validated this myself manually. The zero-ref branch of
`addWithIdContext` incremented `living` unconditionally even if `upsert`
resolved the value to an item that was already alive under a different
ID.
This would cause `living` to be invalid for each time this happened and
the downstream effect was that `count()` drifted. I couldn't find any
crashing or invalid effect except that this caused requested style
memory to be over-provisioned.
cc @qwerasd205 since its ref counted set, but I did this work manually
❤️
For middle-click-action
* Kept the option "primary-paste" instead of "paste-primary" to keep
backwards compatibility
* Added the option "clipboard-paste"
For copy-on-select
* Added the both, none and primary options
Updated config documentation
Note: No AI was used, Even though I don't know Zig, I looked at the code
and the modifications seemed easy enough
Closes#12600
Before this change, ghostty frequently logs the following warning, even
though a `gtk-xft-dpi` value of `-1` is valid and indicates default
scaling.
```
warning(gtk_ghostty_surface): gtk-xft-dpi has invalid value (-1), using default
```
From [the gtk
docs](https://docs.gtk.org/gtk4/property.Settings.gtk-xft-dpi.html):
> The font resolution, in 1024 * dots/inch.
>
> -1 to use the default value.
Before this change, ghostty frequently logs the following warning, even though a `gtk-xft-dpi` value of `-1` is valid and indicates default scaling.
```
warning(gtk_ghostty_surface): gtk-xft-dpi has invalid value (-1), using default
```
From [the gtk docs](https://docs.gtk.org/gtk4/property.Settings.gtk-xft-dpi.html):
> The font resolution, in 1024 * dots/inch.
>
> -1 to use the default value.
A follow on for #14035, we can now fix a long standing
effiency/performance bug now that we park the display link while idle.
This actually could cause "animated" un-focused windows to use more GPU
than their focused counterparts. (AI Agent interfaces seem to love
animation).
6ae1784f4
Unfocused surfaces stopped the CVDisplayLink and encoded a GPU frame on
every PTY wakeup. A burst of close writes became that many Metal submits
instead of one vsync.
Keep the link running while the surface is visible and dirty or
animating, whether or not it is focused. Idle surfaces still park.
Reported in https://github.com/ghostty-org/ghostty/discussions/14064
I validated this myself manually. The zero-ref branch of `addWithIdContext`
incremented `living` unconditionally even if `upsert` resolved the value
to an item that was already alive under a different ID.
This would cause `living` to be invalid for each time this happened and
the downstream effect was that `count()` drifted. I couldn't find any
crashing or invalid effect except that this caused requested style memory
to be over-provisioned.
Update the macOS Sparkle dependency from 2.9.0 to 2.9.4.
This keeps the Swift package resolution and all tag/tip release workflow
downloads aligned on the same version. Sparkle 2.9.2 included fixes for
GHSA-g3hp-f6mg-559v and GHSA-hg88-v3cw-3qrh; 2.9.4 is the current stable
release.
Validation:
- verified the 2.9.4 release contains
`Sparkle-for-Swift-Package-Manager.zip`
- verified the lockfile revision matches the 2.9.4 tag
- `jq empty` on `Package.resolved`
- `git diff --check`
I could not run Xcode package resolution locally because the active
developer directory is Command Line Tools rather than a full Xcode
installation.
The Zig 0.16.0 update dropped the negation from the std default
(!strip_debug_info), disabling stack traces in every unstripped build.
AI disclosure: Claude Fable was used to diagnose the problem and find
the fix. Commit message was written by me.
Claude-Session: https://claude.ai/code/session_01QfzQME46DQXwMWa43bQaa3
Fixes#14037 where dragging the surface from a tab with just a single
surface to another tab causes a crash.
The cause of the crash is a stale pointer to the property binding
created in `Surface.bindIsSplit`. When the surface is moved,
`SplitTree.moveSplit` first updates the two split tree data structures
of the source/target tab and then calls `bindIsSplit` to bind the
`is-split` property of the moved surface to the `SplitTree` widget in
the target tab. When `bindIsSplit` is called, the `SplitTree` widget in
the source tab has already been destroyed (because the source tab is now
empty) which causes the old binding to be freed automatically and the
pointer `Surface.is_split_binding` becomes stale. `bindIsSplit` then
tries to run `is_split_binding.unbind()` which causes the crash.
When you create a binding with `bindProperty`, the binding itself owns
the initially created reference and it gets freed when the source or
target object of the binding is finalized. To prevent this, we now
create an extra reference to the binding object so that the Surface
widget owns it and is responsible for freeing it. The binding can still
get severed automatically, but the binding object itself will not be
destroyed. This is the solution mentioned in the [GObject
docs](https://docs.gtk.org/gobject/method.Object.bind_property.html).
Alternatively, using a WeakRef for the pointer would have also worked.
Updated the binding in `SurfaceScrolledWindow` to use the same pattern.
That one was probably fine, because the binding should only be created
once, but it doesn't hurt to be safe.
I reproduced the crash on KDE, on Hyprland I just got a glib critical
error message about the invalid pointer. That probably has to do with
what exactly happens to the freed memory, or maybe differing versions.
#### AI Disclosure
Code and comments were written by myself, used GPT5.6 in researching
gobject binding lifecycles.
The Zig 0.16.0 update dropped the negation from the std default
(!strip_debug_info), disabling stack traces in every unstripped build.
AI disclosure: Claude Fable was used to diagnose the problem and find the
fix. Commit message was written by me.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QfzQME46DQXwMWa43bQaa3
6ae1784f4
Unfocused surfaces stopped the CVDisplayLink and encoded a GPU
frame on every PTY wakeup. A burst of close writes became that many
Metal submits instead of one vsync.
Keep the link running while the surface is visible and dirty or
animating, whether or not it is focused. Idle surfaces still park.
Focus continues to gate cursor blink, custom-shader animation, and
QoS.
Previously, the property binding created in `Surface.bindIsSplit` would
get freed automatically when the source object (the SplitTree widget)
got finalized. A subsequent call to `bindIsSplit` could then cause a
crash by using the stale pointer to the binding. This bug could e.g. be
triggered by dragging the surface from a single-surface tab to another
tab.
We now create an extra reference to the binding object so that Surface
essentially owns the binding and is responsible for freeing it.
Updated the binding in `SurfaceScrolledWindow` to use the same pattern.
That one was probably fine, because the binding is only created once,
but let's be safe.
Erasing a wrapped wide character at the start of a row (`ECH` or `DCH`)
also clears the spacer head it left at the end of the previous row, but
that row was never marked dirty. With both rows visible, an incremental
render kept the stale spacer head on screen until something unrelated
redrew that row.
The clearing happens in the row-start branch of `splitCellBoundary`.
`clearCells` doesn't do dirty tracking, and both callers only mark the
cursor row, so mark the previous row at the point it's mutated.
The added dirty assertions fail without the fix.
## AI Disclaimer
Claude did the heavy lifting - identifying the root cause, generating
code and description. I reviewed and iterated on it to move around and
tweak tests, comments and reduce verboseness. Verified the end user
visible behaviour improvement with a script that coloured the wide
character, which made the stale rendering visible until a switch to the
alt screen and back cleared it it.
Erasing a wrapped wide character at the start of a row (ECH or DCH)
also clears the spacer head it left at the end of the previous row,
but that row was never marked dirty. With both rows visible, an
incremental render kept the stale spacer head on screen until
something unrelated redrew that row.
The clearing happens in the row-start branch of splitCellBoundary.
clearCells doesn't do dirty tracking, and both callers only mark
the cursor row, so mark the previous row at the point it's mutated.
The added dirty assertions fail without the fix.
