#4235 introduced a crash when you closed the last tab in a window. In
`NotebookAdw.closeTab` a `defer` was added that references `self`. If
the last tab is closed we destroy the window. As part of that process
`self` becomes invalid because the window has been de-initialized. The
`defer` fires at the end of the function, referencing the invalid
pointer and causing a crash.
```
info(surface): surface closed addr=7fffe400a000
debug(gtk): window destroy
(process:1032400): Gtk-CRITICAL **: 18:40:17.674: gtk_widget_unparent: assertion 'GTK_IS_WIDGET (widget)' failed
Segmentation fault at address 0x7ffff4dad040
/home/jeff/dev/ghostty/src/apprt/gtk/notebook_adw.zig:128:19: 0x340226a in closeTab (ghostty)
defer self.forcing_close = false;
^
/home/jeff/dev/ghostty/src/apprt/gtk/notebook.zig:157:40: 0x336ca86 in closeTab (ghostty)
.adw => |*adw| adw.closeTab(tab),
^
/home/jeff/dev/ghostty/src/apprt/gtk/Window.zig:468:27: 0x327628d in closeTab (ghostty)
self.notebook.closeTab(tab);
^
/home/jeff/dev/ghostty/src/apprt/gtk/Tab.zig:121:25: 0x336581b in remove (ghostty)
self.window.closeTab(self);
^
/home/jeff/dev/ghostty/src/apprt/gtk/Surface.zig:207:34: 0x326a213 in remove (ghostty)
.tab_ => |t| t.remove(),
^
/home/jeff/dev/ghostty/src/apprt/gtk/Surface.zig:722:30: 0x31e3a3a in close (ghostty)
self.container.remove();
^
/home/jeff/dev/ghostty/src/Surface.zig:733:26: 0x31e1dc4 in close (ghostty)
self.rt_surface.close(self.needsConfirmQuit());
^
/home/jeff/dev/ghostty/src/Surface.zig:925:23: 0x31e143e in handleMessage (ghostty)
self.close();
^
/home/jeff/dev/ghostty/src/App.zig:486:34: 0x31e2d05 in surfaceMessage (ghostty)
try surface.handleMessage(msg);
^
/home/jeff/dev/ghostty/src/App.zig:252:62: 0x31e3005 in drainMailbox (ghostty)
.surface_message => |msg| try self.surfaceMessage(msg.surface, msg.message),
^
/home/jeff/dev/ghostty/src/App.zig:138:26: 0x31e378e in tick (ghostty)
try self.drainMailbox(rt_app);
^
/home/jeff/dev/ghostty/src/apprt/gtk/App.zig:1279:31: 0x31e3e42 in run (ghostty)
try self.core_app.tick(self);
^
/home/jeff/dev/ghostty/src/main_ghostty.zig:112:24: 0x31e52f4 in main (ghostty)
try app_runtime.run();
^
/nix/store/h6lccra69nr23676qq32h9qn1fba24v1-zig-0.13.0/lib/std/start.zig:524:37: 0x31e5e0e in main (ghostty)
const result = root.main() catch |err| {
^
???:?:?: 0x7ffff682a1fb in ??? (libc.so.6)
Unwind information for `libc.so.6:0x7ffff682a1fb` was not available, trace may be incomplete
fish: Job 2, './zig-out/bin/ghostty --config-…' terminated by signal SIGABRT (Abort)
```
As of version 1.0.1 (macOS build) when running the toggle visibility
action a window with tabs is made into multiple windows.
This PR ensures terminal tabs are reconstructed and correctly placed
into its parent window.
# Demo
https://github.com/user-attachments/assets/44f14bca-15a1-4717-ba0a-44f0767feec3
FYI: I will create another PR to ensure the right tab is focused after
the main window is restored.
Solves #4329
Two major changes:
1. Hiding uses `NSApp.hide` which hides all windows, preserves tabs, and
yields focus to the next app.
2. Unhiding manually tracks and brings forward only the windows we hid.
Proper focus should be retained.
Fixes#4799
This PR attempts to reduce the flash caused by the ghost emoji in the
title bar when opening new windows.
## Changes:
- Initialize `SurfaceView.title` with empty string instead of ghost
emoji
- Simplify title computation logic in `TerminalView`
- Adding a 500ms fallback timer for "👻"
- Canceling timer if title is set
## Current Status:
While these changes reduce the initial ghost emoji flash, there's still
a brief moment where a folder emoji appears alone in the title bar when
opening a new window. This suggests there might be a race condition or
timing issue with how the title is being set and updated.
https://github.com/user-attachments/assets/3688c9f3-1727-4379-b04d-0bd6ac105728
Would appreciate feedback on the remaining flash issue and suggestions
for further improvements.
There's one behavioral change here. Before this patch, if
`gtk-titlebar=false` we _never_ created a headerbar. This explicitly
contradicted the comments in the source, and the documentation for
`gtk-titlebar` imply that if a window starts out without a titlebar it
can be brought back later with the `toggle_window_decorations` keybind
action.
After this patch, a headerbar is always created, but if
`gtk-titlebar=false` or `window-decoration=false` it's immediately
hidden.
I'm not sure how this interacts with the current SSD/CSD detection that
seems to happen when running Ghostty on non-Gnome DEs so it'll be
important to get #4724 merged (plus any follow ups) to enable more
explicit control of SSD/CSD.
This is a hack to make it easier for our GitHub branching rules to
require a single check to pass before merging. This lets us describe the
required checks in code rather than via the GH UI.
This is a hack to make it easier for our GitHub branching rules to
require a single check to pass before merging. This lets us describe the
required checks in code rather than via the GH UI.
This PR addresses https://github.com/ghostty-org/ghostty/issues/4732.
While @tristan957 suggested alternative approaches, this implementation
provides a straightforward way to make the menu accessible when the
window decoration is disabled. It follows patterns seen in other GTK
apps for handling submenus, though not strictly in the context menu
format truth be told.
If there’s a better way to approach this or further refinements needed,
I’m happy to discuss and iterate. This has been a minor issue I’ve
encountered personally, and I’d like to help improve the experience for
others as well.
Small video of how it looks:
https://github.com/user-attachments/assets/59548fef-f11c-421f-b05b-be81eab6ce06
Fixes:
https://github.com/ghostty-org/ghostty/issues/4634#issuecomment-2573469532
This commit fixes two issues:
1. `libghostty` must not override ctrl+key inputs if we are in a preedit
state. This allows thigs like `ctrl+h` to work properly in an IME.
2. On macOS, when an IME commits text, we strip the control modifier
from the key event we send to libghostty. This is a bit of a hack but
this avoids triggering special ctrl+key handling.
Fixes: https://github.com/ghostty-org/ghostty/issues/4634#issuecomment-2573469532
This commit fixes two issues:
1. `libghostty` must not override ctrl+key inputs if we are in a preedit
state. This allows thigs like `ctrl+h` to work properly in an IME.
2. On macOS, when an IME commits text, we strip the control modifier
from the key event we send to libghostty. This is a bit of a hack but
this avoids triggering special ctrl+key handling.
Fixes#4801
Our size calculation before improperly used a screens frame instead of
its visibleFrame. Additionally, we didn't properly account for origin
needing to move in order to fit the window on the screen.
Apparently, setting a frame height to high crashes AppKit. The width
gets clamped by AppKit but the height does not. Fun!
