https://bugs.kde.org/show_bug.cgi?id=506513
Friedrich W. H. Kossebau <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #5 from Friedrich W. H. Kossebau <[email protected]> --- Also have hit this multiple times. But only at random. Right now I can mainly reproduce when killing the xdg-desktop-portal-kde process, seems the race condition on first start is more often hit. Had some closer look at the code, to see how that state can be reached. My assumption by brain-only code execution is that there is a race started in AppChooserPortal::ChooseApplicationPrivate() (https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/blob/Plasma/6.5/src/appchooser.cpp?ref_type=heads#L83), by first calling auto appDialog = new AppChooserDialog(/.../); and then appDialog->m_appChooserData->setHistory(options.value("history"_L1).toStringList()); The AppChooserDialog constructor calls QuickDialog::create() which calls engine->loadFromModule(). This starts the async setup of the quick components (AFAIK) of https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/blob/Plasma/6.5/src/AppChooserDialog.qml. While the C++ code in parallel continues and sets the history property of m_appChooserData. That history property is used on the QML side via the property AppChooserData appChooserData as data model for the searchField combobox. The bug now might appear if the searchField combobox component is created and its bindings evaluated when the history property of m_appChooserData is already set, but before the 3rd init step of QQuickComboBox::componentComplete() is called: So in that first evaluation "model: root.appChooserData.history" will already get the final history stringlist value set, and as result the onModelChanged handler invoked. So ready flag is set to true, and the searchfield text set to "". Which again invokes onEditTextChanged, which passes the ready check and sets the filter to the current empty edittext. Next than the componentComplete call stage is reached, and the one of QQuickComboBox called, Which would init/reset the current index to the first list entry, thus also resetting the edit field to the text of it (by some issue currently the history list is filled with desktop app ids, see also https://invent.kde.org/plasma/plasma-integration/-/merge_requests/201). Which then triggers onEditTextChanged once more, which passes as before the ready check and sets the filter to that very first entry in the history list. At least this is my guess from looking at the code lines and comparing with what is seen on the screen and stored as data in the search history state file :) Sadly no setup for testing and thus playing with plasma/portal stuff, also no clue about proper QML code patterns. But perhaps this gives some hints for a proper solution for someone with a clue. (I'd guess the ready flag would need to also depend on the Component.onCompleted handler of the combobox having been passed?). -- You are receiving this mail because: You are watching all bug changes.
