When creating a QDBusInterface instance, if the target application's main thread is blocked (e.g. for ~30 seconds) at the time of connection, the QDBusInterface constructor itself blocks until the target returns to its event loop.

After that, the constructed QDBusInterface reports isValid() == true, but any further usage such as QObject::connect(), property(), or setProperty() calls fail.

This behavior is misleading:

• In such a case, isValid() should return false, since the interface is not actually usable.
• Also, having the QDBusInterface constructor block indefinitely if the server's main thread is stalled is problematic, because the user application has no way to avoid this deadlock scenario.

Steps to Reproduce:

1. Extract and build the attached archive dbus_timeout.zip.
2. Start server.

• If you start client about 10 seconds later, all operations succeed.
• If you start client within 5 seconds, then QObject::connect(), property(), and setProperty() all fail, even though QDBusInterface::isValid() returns true.

Expected Result:

• QDBusInterface::isValid() should return false if the interface cannot actually be used.
• The constructor should not deadlock indefinitely if the server’s main thread is blocked.

Actual Result:

• isValid() incorrectly returns true.
• Constructor blocks until the server event loop becomes responsive, potentially causing application deadlocks.