engine/src/flutter/shell/platform/linux/fl_window_monitor.cc (83-85)

Removing g_signal_handlers_disconnect_by_data(self->window, self) introduces a critical regression.

The Issue

g_signal_connect_object automatically disconnects signal handlers when the target object (self) is finalized, not when it is disposed.

During fl_window_monitor_dispose, g_clear_object(&self->window) is called, which releases the reference to the window. If this is the last reference, the window is destroyed, emitting the "destroy" signal. Because self is only in its dispose phase (and not yet finalized), the weak reference used by g_signal_connect_object is still active, so destroy_cb(self) will be invoked.

Inside destroy_cb, it will call self->on_destroy(self) on a partially disposed FlWindowMonitor object, which can lead to crashes, use-after-free, or infinite recursion.

Solution

We must keep the explicit disconnection of signals in dispose before clearing the window object. Since we are using g_signal_connect_object, we can still avoid tracking individual connection IDs by using g_signal_handlers_disconnect_by_data:

static void fl_window_monitor_dispose(GObject* object) {
  FlWindowMonitor* self = FL_WINDOW_MONITOR(object);

  g_signal_handlers_disconnect_by_data(self->window, self);
  g_clear_object(&self->window);

  G_OBJECT_CLASS(fl_window_monitor_parent_class)->dispose(object);
}

engine/src/flutter/shell/platform/linux/fl_view_monitor.cc (35-37)

Removing g_signal_handlers_disconnect_by_data(self->view, self) introduces a potential crash/regression.

The Issue

g_signal_connect_object automatically disconnects signal handlers when the target object (self) is finalized, not when it is disposed.

During fl_view_monitor_dispose, g_clear_object(&self->view) is called. If the view is destroyed, or if any pending "first-frame" signals are emitted after FlViewMonitor is disposed but before it is finalized, first_frame_cb(self) will be invoked on a partially disposed FlViewMonitor object (where self->view is already NULL), leading to a crash.

Solution

We should keep the explicit disconnection of signals in dispose before clearing the view object. We can still avoid tracking individual connection IDs by using g_signal_handlers_disconnect_by_data:

static void fl_view_monitor_dispose(GObject* object) {
  FlViewMonitor* self = FL_VIEW_MONITOR(object);

  g_signal_handlers_disconnect_by_data(self->view, self);
  g_clear_object(&self->view);

  G_OBJECT_CLASS(fl_view_monitor_parent_class)->dispose(object);
}

engine/src/flutter/shell/platform/linux/fl_keyboard_manager.cc (321-324)

Removing the manual signal disconnection here introduces a potential crash/regression.

The Issue

g_signal_connect_object automatically disconnects signal handlers when the target object (self) is finalized, not when it is disposed.

If the "keys-changed" signal is emitted on self->keymap after FlKeyboardManager is disposed but before it is finalized, keymap_keys_changed_cb(self) will be invoked on a partially disposed FlKeyboardManager object (where self->derived_layout and other fields are already NULL), leading to a crash.

Solution

We should keep the explicit disconnection of signals in dispose. However, we can still achieve the goal of removing the manually tracked connection ID (keymap_keys_changed_cb_id) by using g_signal_handlers_disconnect_by_data:

static void fl_keyboard_manager_dispose(GObject* object) {
  FlKeyboardManager* self = FL_KEYBOARD_MANAGER(object);

  g_clear_object(&self->key_embedder_responder);
  g_clear_object(&self->key_channel_responder);
  g_clear_object(&self->derived_layout);
  
  if (self->keymap != nullptr) {
    g_signal_handlers_disconnect_by_data(self->keymap, self);
  }
  
  g_clear_object(&self->cancellable);

  G_OBJECT_CLASS(fl_keyboard_manager_parent_class)->dispose(object);
}

engine/src/flutter/shell/platform/linux/fl_view.cc (606-611)

Removing the manual signal disconnection for the cursor handler here introduces a potential crash/regression.

The Issue

g_signal_connect_object automatically disconnects signal handlers when the target object (self) is finalized, not when it is disposed.

If the "cursor-changed" signal is emitted on the mouse cursor handler after FlView is disposed but before it is finalized, cursor_changed_cb(self) will be invoked on a partially disposed FlView object, leading to a crash.

Solution

We should keep the explicit disconnection of signals in dispose. We can still achieve the goal of removing the manually tracked connection ID (cursor_changed_cb_id) by using g_signal_handlers_disconnect_by_data:

  if (self->engine != nullptr) {
    FlMouseCursorHandler* handler =
        fl_engine_get_mouse_cursor_handler(self->engine);
    g_signal_handlers_disconnect_by_data(handler, self);

    // Release the view ID from the engine.
    fl_engine_remove_view(self->engine, self->view_id, nullptr, nullptr,
                          nullptr);
  }

engine/src/flutter/shell/platform/linux/fl_view.cc (618-627)

Removing the manual signal disconnections for the engine signals here introduces a potential crash/regression.

The Issue

g_signal_connect_object automatically disconnects signal handlers when the target object (self) is finalized, not when it is disposed.

If "on-pre-engine-restart" or "update-semantics" signals are emitted on self->engine after FlView is disposed but before it is finalized, the callbacks will be invoked on a partially disposed FlView object, leading to a crash.

Solution

We should keep the explicit disconnection of signals in dispose. We can still achieve the goal of removing the manually tracked connection IDs (on_pre_engine_restart_cb_id and update_semantics_cb_id) by using g_signal_handlers_disconnect_by_data:

  if (self->engine != nullptr) {
    g_signal_handlers_disconnect_by_data(self->engine, self);
  }

engine/src/flutter/shell/platform/linux/fl_window_state_monitor.cc (89-92)

Removing the manual signal disconnection here introduces a potential crash/regression.

The Issue

g_signal_connect_object automatically disconnects signal handlers when the target object (self) is finalized, not when it is disposed.

If the "window-state-event" signal is emitted on self->window after FlWindowStateMonitor is disposed but before it is finalized, window_state_event_cb(self) will be invoked on a partially disposed FlWindowStateMonitor object (where self->messenger is already NULL), leading to a crash.

Solution

We should keep the explicit disconnection of signals in dispose. We can still achieve the goal of removing the manually tracked connection ID (window_state_event_cb_id) by using g_signal_handlers_disconnect_by_data:

static void fl_window_state_monitor_dispose(GObject* object) {
  FlWindowStateMonitor* self = FL_WINDOW_STATE_MONITOR(object);

  g_signal_handlers_disconnect_by_data(self->window, self);
  g_clear_object(&self->messenger);

  G_OBJECT_CLASS(fl_window_state_monitor_parent_class)->dispose(object);
}