TypeError: can't access property "get_client_type", win is null — null window reference during close animation & GC callback blocked due to signal handler leak

[kissunyeason]

Environment

• Extension version: 14
• GNOME Shell version: 49.4
• Kernel: 6.18.13-200.fc43.x86_64
• Fedora: Fedora Silverblue 43 (Atomic), up to date as of 2026-03-07
• Session type: Wayland

Description

Two related issues observed consistently in journal logs:

Bug A — Null window reference during window close animation

When a window is closed and its destroy animation plays, refreshRoundedCorners is called after the window actor has already been destroyed, causing a TypeError. This happens reproducibly on every window close that triggers a close animation.

Bug B — GC callback blocked due to lingering signal handlers

GNOME Shell repeatedly logs Attempting to call back into JSAPI during the sweeping phase of GC, with the offending signal identified as size-changed on MetaShapedTexture. This indicates signal handlers connected by the extension are not being disconnected when window actors are destroyed, causing accumulation over time (handler IDs in the logs reach six digits, e.g. 102792, 213784).

Logs

Bug A — stack trace (from journalctl):

gnome-shell[57052]: JS ERROR: TypeError: can't access property "get_client_type", win is null
  getRoundedCornersEffect @ rounded-window-corners@fxgn/manager/utils.js:50:5
  refreshRoundedCorners @ rounded-window-corners@fxgn/manager/event_handlers.js:164:43
  applyEffectTo/< @ rounded-window-corners@fxgn/manager/event_manager.js:119:18
  _destroyWindowDone @ gnome-shell/ui/windowManager.js:1590:21
  onStopped @ gnome-shell/ui/windowManager.js:1558:39
  _makeEaseCallback/< @ gnome-shell/ui/environment.js:68:22
  _easeActor/< @ gnome-shell/ui/environment.js:175:70

Bug B — GC warning (repeated many times per session):

gnome-shell[57052]: Attempting to call back into JSAPI during the sweeping phase of GC.
This is most likely caused by not destroying a Clutter actor or Gtk+ widget with
::destroy signals connected. Because it would crash the application, it has been
blocked and the JS callback not invoked.

Stack trace for context 0x56323928a010:
  The offending signal was size-changed on MetaShapedTexture 0x56323b6d9ec0.

Additionally, gsignal.c:2700: instance '...' has no handler with id 'XXXXXX' is logged with ever-increasing handler ID numbers, confirming handlers are accumulating and never cleaned up.

Root cause hypothesis

In event_manager.js, signal connections made via applyEffectTo are not fully disconnected when the associated window is destroyed. utils.js:getRoundedCornersEffect at line 50 does not guard against win being null, which it will be after _destroyWindowDone runs.

[kissunyeason]

This might be related to #118 (VRAM memory leak).

The symptoms I'm seeing in journalctl are consistent with a signal handler accumulation issue:

• Attempting to call back into JSAPI during the sweeping phase of GC — repeated many times per session, with the offending signal identified as size-changed on MetaShapedTexture
• gsignal.c:2700: instance '...' has no handler with id 'XXXXXX' — handler IDs reach six digits (e.g. 102792, 213784), increasing over time without being cleaned up
• JS ERROR: TypeError: can't access property "get_client_type", win is null — triggered during window close animations via _destroyWindowDone

These suggest that signal handlers connected by the extension are not being fully disconnected when window actors are destroyed, which matches the memory leak described in #118. The GC warnings indicate callbacks are still firing during garbage collection on objects that should have been cleaned up.

Running on AMD hardware (Lenovo IdeaPad Pro 5 14AHP9), GNOME Shell 49.4, Wayland.