Search field: Keystrokes get mixed up

Bug #1783392 reported by Uwe Klotz on 2018-07-24
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mixxx
Medium
Uwe Klotz

Bug Description

Since building with Qt5 I noticed the following behavior: Keystrokes get mixed up when you continue typing in the search edit field while the UI is frozen during a database query that has been triggered by a typing timeout.

The typing timeout of 300 ms is too low for finishing typical search queries. The larger your library the more serious those intermediate and unwanted disruptions become and the more difficult it is to correct the wrong ordering of letters and to finish your query as intended. Totally annoying and hardly usable!

I propose to at least double the timeout to 600-800 ms. You can trigger a search manually at any time just by pressing Return, instead of stop typing and waiting for the timeout kicking in. The current timeout of only 300 ms combined with the keystroke issue is unacceptable.

I also noticed that the state management and signal handling in WSearchLineEdit is unnecessarily complex. I already fixed it, but unfortunately this did not fix the mixed up keystrokes.

Uwe Klotz (uklotzde) on 2018-07-24
Changed in mixxx:
status: New → In Progress
tags: added: qt5
Daniel Schürmann (daschuer) wrote :

I cannot confirm the issue on Ubuntu Xenial with a library on a spinning HD and 17k titles.
Are you sure that this is a regression from the Qt5 change?

Uwe Klotz (uklotzde) wrote :

Definitely a Qt5 issue. I switched a few times back and forth between Qt4 and Qt5 during development and this happens only on Qt5. There is even not a clear pattern when this happens exactly. The only common pattern is after continue typing while a search freezes the UI *sigh*. If it happens it feels like you are stuck in the mistyping mode, it's difficult to complete the search without subsequent errors.

Using Wayland/XWayland on Fedora, which might be another necessary precondition. I should try the X only fallback.

RJ Skerry-Ryan (rryan) wrote :

I think 300ms vs 600ms makes a meaningful difference in the "feel" of interactivity -- is increasing the timeout necessary to fix this bug?

Uwe Klotz (uklotzde) wrote :

We can keep the 300 ms. I will simply disable in in my personal patched version. A search can be started reliably at any time just by pressing ENTER.

The search-as-you-type feature does not fit into the current architecture. In combination with this bug it gets you into trouble if each database query takes >2 sec and freezes the GUI. You need multiple tries with enforced waiting periods in between to correct and finish your intended search, which is unusable in live situations.

Optionally the timeout could be configurable by the user. At least until we have a solution that doesn't cause major usability issues depending on your personal typing speed and habits.

Uwe Klotz (uklotzde) wrote :

Pushed back to the 2.3 release. We will see if this issue affects multiple users after releasing 2.2.

Changed in mixxx:
milestone: 2.2.0 → 2.3.0
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers