Fix window wrapper disabling prematurely on close request

[Shakai-Dev]

Fixes #1165

TL;DR

This PR fixes an issue where attempting to close a floating game view window in projects with auto_accept_quit set to false causes the window frame & decorations to be disabled/hidden while the game process & remote debugger remain running in a "ghost" state.

The Problem

In GameView::_window_close_request(), window_wrapper->set_window_enabled(false) was being called unconditionally at the beginning of the function before delegating the close request to the running game process.

When a project has auto_accept_quit = false, the game engine intentionally ignores NOTIFICATION_WM_CLOSE_REQUEST & waits for script logic to explicitly call get_tree().quit(). Because GameView had already disabled the window_wrapper, the UI container hid its window frame/decorations immediately, leaving the game process running continuously in the background without a visible outer window or title bar.

The Fix

• Moved window_wrapper->set_window_enabled(false) & embedded_process->reset_timers() into the branch reserved for forced resets (when the game is paused or embedding is still in progress).

• Allowed graceful close requests (embedded_process->request_close()) to leave the window_wrapper active.

  • If auto_accept_quit is true, the game process exits naturally, triggering _stop_pressed(), which safely handles disabling the window wrapper.

  • If auto_accept_quit is false, the game process ignores the close request & the window wrapper remains open & interactive as expected.

Summary by CodeRabbit

• Bug Fixes
  • Improved closing behavior for embedded games by adjusting how the app terminates or requests closure based on whether the game is paused or still embedding.
  • When the game is fully embedded and running, close requests are now passed to the game for in-game quit handling, preserving expected quit behavior.
  • Updated termination handling for paused or in-progress embedding states to ensure correct shutdown behavior.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 68d33d2f-5660-4de4-ab91-ea166c29e7b3

📥 Commits

Reviewing files that changed from the base of the PR and between 7adeba1 and b11c75e.

📒 Files selected for processing (1)

• editor/run/game_view_plugin.cpp

🚧 Files skipped from review as they are similar to previous changes (1)

• editor/run/game_view_plugin.cpp

---

Walkthrough

_window_close_request() preserves the embedded window wrapper for graceful close requests, allowing the game process to handle NOTIFICATION_WM_CLOSE_REQUEST; forced-stop paths still reset timers and disable the wrapper.

Changes

Embedded game close handling

Layer / File(s)	Summary
Close-request control flow editor/run/game_view_plugin.cpp	Timer resets and window_wrapper disabling apply only when embedding is incomplete or the game is paused; completed, unpaused embedding calls embedded_process->request_close().

Estimated code review effort: 2 (Simple) | ~10 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly describes the main change: delaying window wrapper disabling until a close request needs a forced reset.
Linked Issues check	✅ Passed	The change addresses issue #1165 by preserving decorations and delegating graceful close requests to the game process when Auto Accept Quit is off.
Out of Scope Changes check	✅ Passed	The PR appears narrowly focused on the close-request behavior in one file, with no unrelated changes visible in the summary.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[GeneralProtectionFault]

I can confirm the disappearing decorations stay.
Worth noting, they only disappear in the first place under X11.
After this fix, the decorations stay under both Wayland & X11, and the window will not close by clicking the 'X'.
Not sure if this is intended behavior or not, but the PR addresses the issue, so all good on that front.

[JoltedJon]

From holonet's testing on my behalf (due to hyprland not having decorations) this PR seems solid