DropTarget: Fix critical if reject drop pre-enter
authorDaniel Boles <dboles.src@gmail.com>
Tue, 27 Jun 2023 20:03:10 +0000 (21:03 +0100)
committerDaniel Boles <dboles.src@gmail.com>
Tue, 27 Jun 2023 20:37:32 +0000 (21:37 +0100)
commitdfa6591675c0c319161c5a725b7999eef6aba48b
treeb29fc89597c9cafcbfebfbc31dbfa8193590e1d5
parent6252517aacccfa8377b841a1e92bf93d7e67a487
DropTarget: Fix critical if reject drop pre-enter

Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/5922

The docs of `Gtk.DropTarget::accept` say this:
> If the decision whether the drop will be accepted or rejected depends
> on the data, [`::accept`] should return `TRUE`, [`:preload`] should be
> set and the value should be inspected via the `::notify:value` signal,
> calling `gtk_drop_target_reject()` if required.

But this pattern causes a CRITICAL, given these steps:
* Create a `DragSource` and `DropTarget`
* Keep the default `::accept` handler and set `:preload` to `TRUE`
* Connect to `notify::value` and therein call `DropTarget.reject()`
* CRITICAL at `DropTarget.enter()`→`Drop.get_actions()` on NULL instance

We should let the documented case work without a CRITICAL or worse, null
deref. And per @otte on the bug, we should bail earlier before `::enter`
& setting `GTK_STATE_FLAG_DROP_ACTIVE`; neither should occur if rejected

This fixes that, by checking after `start_drop()` when notifications are
thawed, whether any handler has `reject()`ed & set our `drop` to `NULL`.
gtk/gtkdroptarget.c