Run ./tests/testflowbox with:
  * activate on single click = TRUE
  * selection mode = MULTIPLE

Click (press and release) any one of the children. It will emit 'child-activated', which is fine.

Now press the mouse button on the same child near one of its edges, and hold it for a bit for the multi-press gesture to emit 'stopped'. Start moving the mouse without releasing the button inside the child. Move enough for the drag gesture to kick in without leaving the child and then stop. You will see that it emitted 'child-activated' even though you never released the button.

It is a problem for GdMainIconBox (see bug 774914) where 'child-activated' on a selected child toggles the selection. For example, you have selected three images in gnome-photos and you initiate a drag-and-drop. Due to 'child-activated' being emitted midway through the DnD, you will lose one of the images from the selection.

This is caused by the drag gesture's 'update' handler claiming the sequence. That invokes the multi-press gesture's 'released' handler, which emits 'child-activated'. One solution is to cancel the multi-press's 'released' by listening to its 'stopped'.

Related to this ...

What is the purpose of priv->active_child_active, and why do we queue a draw when it is updated in gtk_flow_box_update_active? It seems priv->active_child_active is meant to track whether the mouse pointer is within the same child between the button being pressed and released. If that's all, then why the re-draw?