https://bugs.kde.org/show_bug.cgi?id=521598

cwo <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
      Latest Commit|                            |https://invent.kde.org/plas
                   |                            |ma/milou/-/commit/e5d918683
                   |                            |9fca412e99872d8d92c4cf154af
                   |                            |343c
         Resolution|---                         |FIXED
            Version|                            |6.7.1
  Fixed/Implemented|                            |
                 In|                            |

--- Comment #16 from cwo <[email protected]> ---
Git commit e5d9186839fca412e99872d8d92c4cf154af343c by Christoph Wolk.
Committed on 22/06/2026 at 20:11.
Pushed by cwo into branch 'master'.

lib/ResultsView: consider all data changes results

When the user changes the search term, we block activation of entries
until the runners had time to report results, so that pressing Return
will not activate the old results and instead queue the press to run
when the first batch of new results is there. In 6.6 and prior, we only
did this while we did not have any results. The problem is that we do
this when new results are inserted. This is the case for most queries,
but will fail if (a) all results are ready within the first result
window (b) the results are exactly the same as for the query before
changing the search term. (This is somewhat hard to trigger in regular
use, but for implementation reasons, when automatic seach completion is
enabled in KRunner settings, continuing to type the automatic match is
considered a new search term even when it is exactly the same as before
which guarantees to have a new search with exactly the same matches.

Instead, also handle this in the model's onDataChanged, and also trigger
any queued Return presses in that case while we're at it. Similarly for
removing rows, in case there is a query that changes absolutely nothing
except removing matches. To be super-defensive in case e.g. future
optimizations in Krunner avoid dataChanged signals if the data didn't
actually change, also make sure that we do this when the query is
finished - makes no sense to wait if there is no query running.
FIXED-IN: 6.7.1

----

Test plan

- Disable any runners that may yield slow results, like Browser tabs (them not
being ready after 250 seconds is removing them, then inserting them, so hides
the issue)
- Enable automatic search completion
- Search for "kate" to make sure it's an autocompletion option
- Clear the search, type "k". It should auto-complete to "kate", with "ate"
highlighted.
- Type "a". Now "te" should be highlighted, and the results exactly the same as
before.
- Press Return and nothing happens, fixed with patch.

M  +24   -6    lib/ResultsView.qml

https://invent.kde.org/plasma/milou/-/commit/e5d9186839fca412e99872d8d92c4cf154af343c

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to