https://bugs.kde.org/show_bug.cgi?id=506513
--- Comment #6 from Friedrich W. H. Kossebau <[email protected]> --- 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? -- You are receiving this mail because: You are watching all bug changes.
