QWidgets stop responding to simulated mouse events

packetpirate

I have an application with a login window that has a QComboBox for the user ID and QLineEdit for the password. In the background I have running a custom touchscreen driver I had to write originally for when the application was running on Scientific Linux 6.4 (Centos) and did not have a native driver, nor a driver available from the vendor. My driver does pretty much exactly what Qt's touch handler does in that it synthesizes mouse events from touch events. This works pretty much flawlessly in most of the application except for the login window.

If I use the on-screen keyboard to type the login, but use an incorrect password, it will first call accept() on the login window, then re-show the dialog when the login fails. At that point, the on-screen keyboard buttons and the user ID and password fields no longer respond to my touch events. There is one other QComboBox on the form however, that DOES respond to the touch events, and after selecting an item from it, even if it's the same item that was already selected, suddenly the form items start to respond to touch again.

When the reshow method is called for the login dialog, all it really does is clear the appropriate form elements (password field) and then show/hide the widgets needed on the dialog and centers the dialog on the screen.

Also, this is only a problem with the touch inputs, as clicking the form elements with the actual mouse responds as it should and corrects the problem. So only the synthesized mouse events behave this way.

What could be causing the form to behave this way? If it matters, this is a Qt 5.15 application running on RedHat 8.4. Also, the Qt::WA_DeleteOnClose property of the login window is set to false.

SGaist

Hi and welcome to devnet,

Are you using a new dialog or the same every time ?

packetpirate

@SGaist It's the same dialog. As I said, Qt::WA_DeleteOnClose is set to false and the dialog is just re-shown after a failed login.

SGaist

What happens if you use a new dialog ?

jeremy_k

I've seen similar behavior with a driver that failed to send touch release events. One of the widgets (or rather Item, using quick not widgets) was consuming all input while waiting for the release that never arrived. We diagnosed it by installing an event filter on the QGuiApplication instance.

packetpirate

@jeremy_k Could you give more details? What did the event filter do?

packetpirate

@SGaist Tried this and the behavior is the same.

packetpirate

@packetpirate said in QWidgets stop responding to simulated mouse events:

@SGaist Tried this and the behavior is the same.

Correction. I had only commented out where we set it to false. Setting it explicitly to true results in the dialog never coming back and the process hanging there.

jeremy_k

@packetpirate said in QWidgets stop responding to simulated mouse events:

@jeremy_k Could you give more details? What did the event filter do?

I find event filters to be a useful debugging aid, to see what events are delivered, to which recipient, and when.

struct Object : public QObject {
    bool eventFilter(QObject *watched, QEvent *event) override {
        qDebug() << watched << event->type();
        return QObject::eventFilter(watched, event);
    }
};

int main() {
    QApplication app;
    Object filter;
    app.installEventFilter(&filter);
    return app.exec();
}

packetpirate

@jeremy_k Ah, I see. This won't really help me though since the events aren't delivered to the dialog. They're delivered straight to the widget. When I synthesize the mouse events from the touchscreen data, I get the coordinates and use the QApplication::widgetAt() method to identify the widget underneath the touch point, and then call QApplication::postEvent() to send the mouse event directly to that widget. The widgets are part of the dialog and defined in the UI file, so they don't have their own class where I can define an eventFilter for them.

jeremy_k

@packetpirate said in QWidgets stop responding to simulated mouse events:

@jeremy_k Ah, I see. This won't really help me though since the events aren't delivered to the dialog.

That's why the example installs the event filter on the QApplication. This allows it to see events delivered to all QObject instances.

packetpirate

@jeremy_k Alright, so this did finally help me get some new information, though I'm not sure what it means yet. I added debug messages both where I created the mouse events for press and release, and installed an event filter that does what you showed, but only prints a debug message if it's a mouse press or release event.

The messages show properly on both sides no matter what, so the buttons ARE receiving the mouse events. But I also added debug messages where I manually set focus on certain types of widgets, such as QLineEdit and QComboBox which are present on the login form. I have a message before and after calling setFocus() on them to verify the focus gets set.

Before the failed login, the focus is properly set when I touch the password field. But after a failed login, when I touch the password field, my debug messages indicate even after manually setting focus on the widget, it doesn't have focus. So even though the on-screen keyboard buttons are receiving the events, there's nowhere to output the text I'm typing.

But there's one specific QComboBox on the login form that after I press it and select something, suddenly pressing the password field will properly set the focus again and allow me to type.

What's going on here?

packetpirate

After playing around some more, there is some new information that is less specific to our application.

It seems that after the failed login, even the mouse can't give focus to QLineEdit fields. The physical keyboard can still type in these fields, but the on-screen keyboard cannot. If we login properly and then logout, the fields work properly again, and they also start working again after clicking or touching the QComboBox and selecting a different item.

I suspect this may be a bug specific to the OS (window manager) or the version of Qt we're using.

Are there any known bugs like this in RedHat 8.4 or Qt 5.15? We have been using this same touchscreen driver and application code in previous releases that were on Scientific Linux 6.4 and did not have this issue, which is why I believe the problem lies in Qt or RedHat.

jeremy_k

I wonder if there's something grabbing the keyboard, mouse, or otherwise changing focus unexpectedly. QApplication::focusChanged() is good for catching focus changes when they happen.

The QEvent::Focus(In|Out|AboutToChange) and QEvent::Grab(Mouse|Keyboard) events can be picked up via the event filter.

packetpirate

@jeremy_k After adding those events to the event filter, I don't see anything suspicious grabbing the mouse or keyboard. I don't get a single grab event anywhere. Plenty of focus changing, but none that look out of place.