See the attached reproduction. In there we have a QScrollArea placed as a foreign view into a regular NSWindow (along side a native NSButton). The scroll area has a QScroller grabbing it, so the scroll area (displaying a large image of a holiday greeting) can be panned around by holding the left mouse button.

Every time the panning gesture starts, a warning is logged to the console: "QGestureManager::deliverEvents: could not find the target for gesture".

The gesture still works somehow (not sure how), but based on the code of QGestureManager, the case of the gesture start not finding its' target widget is marked as unlikely, and is probably unexpected.

The cause of the warning is QApplication::topLevelAt returning a nullptr for gesture's hotspot point. This is shown by clicking the NSButton, which prints to the console proof that the Qt widget is part of QApplication::topLevelWidgets return value, but calling QApplication::topLevelAt on a point within its' geometry returns null. 

The underlying cause of that is that QCocoaScreen::topLevelAt completely ignores all NSWindow objects that don't conform to the QNSWindowProtocol protocol (that is, not controlled by Qt) - even though a Qt controlled view which is a top level from Qt's perspective could be within its' view hierarchy.

Comparing same scenario with other desktop platforms:

• xcb - Works as expected, with the same Qt widget placed into a Gtk3 host window via XEmbed.
• wayland - It does not appear to be applicable, as such form of embedding does not appear to be possible...
• windows - reproduction not yet complete, although based on inspection of the code, it should work correctly.