Qt relies internally on connections to the destroyed() signal of application-objects, for example to clean up accessibility interface implementations or other data structures that would otherwise grow or hold danging pointers. The QObject::disconnect function is already documented to be potentially dangerous, as a wildcard call (with signal, receiver, and method defaulted to nullptr) will disconnect everything. However, what happpens to work in one Qt release might break things in another if we add code that relies on connections to destroyed(). To make users aware of the danger of a wildcard disconnect call, and to help with fixing the issues that might arise, emit a warning when a wildcard disconnect() breaks an existing connection to the sender's destroyed() signal. Do this while we hold the connection mutex, and only if all parameters to the disconnect() call are wildcarded. This happens very rarely, and should never happen in performance critical code. Fix the only test I found emitting this warning due to a wildcard disconnect (the drag'n'drop subsystem relies on the destroyed signal). Store the only relevant connection instead so that we can disconnect when done. Fixes: QTBUG-134610 Pick-to: 6.9 6.8 Change-Id: I9e6dcade0d5572345b71e3e8f06902bbea1ef89a Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>