Skip to content

macOS: fix surface focus/render state after dragging in to to another window/tab#12338

Open
bo2themax wants to merge 2 commits intoghostty-org:mainfrom
bo2themax:fix-split-drag
Open

macOS: fix surface focus/render state after dragging in to to another window/tab#12338
bo2themax wants to merge 2 commits intoghostty-org:mainfrom
bo2themax:fix-split-drag

Conversation

@bo2themax
Copy link
Copy Markdown
Member

@bo2themax bo2themax commented Apr 19, 2026

Fixes 2 bugs

  1. After dragging a non-focused surface from window A to window B quickly without making B the key window, the focused surface in window A is not receiving keyDown events.
Screen.Recording.2026-04-19.at.20.51.40.mp4
  1. Dragging a split into a different tab causes split to function incorrectly #12343 After dragging a surface from tab A to tab B within the same window, the dragged surface is not rendering input correctly.

The reason the thread is stuck is because the surface's occlusion state is set to invisible after target tab's activate while dragging, since the dragged surface is still in previous tree before dropping, and after dropping the occlusion state of this surface is not updated to visible, which causing the surface is accepting input but not rendering.

Screen.Recording.2026-04-19.at.23.15.33.mp4

@bo2themax bo2themax requested a review from a team as a code owner April 19, 2026 18:54
@ghostty-bot ghostty-bot Bot added the os/macos label Apr 19, 2026
@bo2themax bo2themax closed this Apr 19, 2026
@bo2themax bo2themax reopened this Apr 19, 2026
@bo2themax bo2themax changed the title macOS: fix first responder after dragging a non-focused surface macOS: fix surface focus/render state after dragging in to to another window/tab Apr 19, 2026
@bo2themax bo2themax force-pushed the fix-split-drag branch 2 times, most recently from 1ae49bd to ffa6c0b Compare April 30, 2026 16:26
bo2themax added 2 commits May 6, 2026 18:52
This fixes a bug: after dragging a non-focused surface from window A to window B **quickly without making B the key window**, the focused surface in window A is not receiving `keyDown` events.
…b within the same window

The reason the thread is stuck is because the surface's occlusion state is set to invisible after target tab's activate while dragging, since the dragged surface is still in previous tree before dropping, and after dropping the occlusion state of this surface is not updated to visible, which causing the surface is accepting input but not rendering.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant