When opening certain items with "Open with", a flatpak address is aready there. However, the app itself doesn't appear. The issue is either one of these: 1- Flatpak addresses doesn't work for finding the app with their proper name. 2- "Open with" should search the proper name of flatpaks, instead of address.
Confirmed on master. Also, please use the bug report template next time.
Is this the same as bug 508469?
Yep, looks like the same thing. Yours is newer (and not in the right place), so I'll make this the master bug report for it.
*** Bug 508469 has been marked as a duplicate of this bug. ***
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?).
Seems my brain execution had flaws, as by more execution on actual CPU: Came up with a way how to test things locally, so added some debug output to xdg-desktop-portal-kde's AppChooserDialog.qml, i.e. added some console.log() calls to lots of combobox searchField's onXChanged handlers, which gave me this output on first usage (with Gwenview being the first list entry): qml: onModelChanged-editText:-ready:false qml: Component.onCompleted qml: onCurrentIndexChanged-editText:-ready:true-index:0 qml: onEditTextChanged-editText:Gwenview-ready:true qml: onModelChanged-editText:Gwenview-ready:true qml: onEditTextChanged-editText:-ready:true qml: onEditTextChanged-editText:Gwenview-ready:true The last change, where editText is changed back to Gwenview, the first list entry, only happened on the first usage in the same running process. And there seemed no setting done in AppChooserDialog.qml which could explain the change. Instead looking at Qt's quicktemplates/qquickcombobox.cpp sources there are multiple reasons why QQuickComboBox::setEditText would be called and then also change the text and emit editTextChanged. So I ran xdg-desktop-portal-kde inside gdb, and looked at the backtrace for when that last reset to Gwenview happened. Which yields: at /usr/src/debug/qtdeclarative-everywhere-src-6.10.1/src/quicktemplates/qquickcombobox.cpp:1644 1644 emit editTextChanged(); (gdb) bt #0 QQuickComboBox::setEditText (this=0xc31b10, text=...) at /usr/src/debug/qtdeclarative-everywhere-src-6.10.1/src/quicktemplates/qquickcombobox.cpp:1644 #1 0x00007fffed831c04 in QQuickComboBoxPrivate::updateCurrentText (this=this@entry=0xda8d40) at /usr/src/debug/qtdeclarative-everywhere-src-6.10.1/src/quicktemplates/qquickcombobox.cpp:552 #2 0x00007fffed831d69 in QQuickComboBoxPrivate::updateCurrentElements (this=0xda8d40) at /usr/src/debug/qtdeclarative-everywhere-src-6.10.1/src/quicktemplates/qquickcombobox.cpp:572 #3 QQuickComboBoxPrivate::updateCurrentElements (this=0xda8d40) at /usr/src/debug/qtdeclarative-everywhere-src-6.10.1/src/quicktemplates/qquickcombobox.cpp:566 #4 0x00007fffed831f4e in QQuickComboBox::event (this=0xc31b10, e=0xc1bd00) at /usr/src/debug/qtdeclarative-everywhere-src-6.10.1/src/quicktemplates/qquickcombobox.cpp:2290 So by the line qquickcombobox.cpp:2290 seems this reset of the edit text field happens due to QEvent::LanguageChange event actually, being delivered/processed only later on the startup (backtrace goes back to event loop). See https://invent.kde.org/qt/qt/qtdeclarative/-/blob/6.10.1/src/quicktemplates/qquickcombobox.cpp?ref_type=heads#L2290 Seems like a(nother) flaw in QtQuick Controls' ComboBox with editable text field. One would expect it would not overide a custom changed edit text value. Not sure what to do. Hopefully you who write QML code do :) Best might be a bug fix with Qt's code?
Before this got lost in the wall of text before: https://invent.kde.org/plasma/plasma-integration/-/merge_requests/201 is up to at least use the app name instead of the app id for the entries in the filter history.