Summary: | Searching twice from an app page: second search does nothing | ||
---|---|---|---|
Product: | [Applications] Discover | Reporter: | Nate Graham <nate> |
Component: | discover | Assignee: | Aleix Pol <aleixpol> |
Status: | VERIFIED FIXED | ||
Severity: | normal | CC: | bugseforuns, epost.kde |
Priority: | NOR | ||
Version: | 5.12.0 | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
Latest Commit: | https://commits.kde.org/discover/4e7c19704ec211b95eff7d93ce3cabdf538ad7a4 | Version Fixed In: | |
Attachments: |
Can't reproduce
2nd way to reproduce (which also froze Discover) |
Description
Nate Graham
2018-02-10 02:53:31 UTC
I cannot reproduce :( Reproduces for me in Kubuntu 17.10 and KDE Neon, FWIW. Created attachment 110569 [details]
Can't reproduce
This is using Neon git unstable packages.
Will try again tonight an see if I can regress it. Can still reproduce in Neon by following the original Steps to Reproduce exactly. Can reproduce on Neon User 5.12.1, but with different steps: 1. Open Discover 2. Click on Applications 3. Write an app name (or click search box and then write the name) and hit enter 4. Click on Back (to take you back to Discover's main menu). This clears the search box. 5. Click on Applications again. 6. Write the exact same search string as in step 3, and hit enter 7. Nothing happens If search strings differ in step 3 and 6, then search completes as expected. I discovered another way to reproduce this: 1. Open Discover 2. Click Settings 3. Type a search string and hit enter (I typed 'libreoffice'; I typed it in Settings by a mistake) 4. Click on Applications 5. Type the search string from step 3 and hit enter 6. Nothing happens Created attachment 110759 [details]
2nd way to reproduce (which also froze Discover)
(In reply to ystein from comment #7) > I discovered another way to reproduce this: > > 1. Open Discover > 2. Click Settings > 3. Type a search string and hit enter (I typed 'libreoffice'; I typed it in > Settings by a mistake) > 4. Click on Applications > 5. Type the search string from step 3 and hit enter > 6. Nothing happens reproducible on Arch Linux, Discover 5.12.1. Should be fixed in the stable branch commit a263fccd2532f04160aa82743f4a0f8172f9af3f (patch) tree 76f168a2aafbcc7caad1f4e0e25567aa18a318f8 parent 4593a765bf211fb7750038acfa20d94fa087be8c (diff) Fix weird behavior on the search field once it's clearedPlasma/5.12 Accept the field after clearing, to make sure we are reporting the right content. The original use case is still broken for me with that, I'm afraid. Important update: this works properly if you've got discover's window maximized or otherwise very wide, which permits you to see the app list as well as the app page at the same time. The second search correctly updates the app list, so if it's visible, there's no bug. But when you're *not* widescreen and can only see the app page, it fails to replace the app page with the just-updated app list. Should be fixed by https://commits.kde.org/discover/4e7c19704ec211b95eff7d93ce3cabdf538ad7a4 Git commit 4e7c19704ec211b95eff7d93ce3cabdf538ad7a4 by Aleix Pol. Committed on 21/02/2018 at 15:43. Pushed by apol into branch 'Plasma/5.12'. Move back to the first page when changing the search M +1 -0 discover/qml/DiscoverDrawer.qml https://commits.kde.org/discover/4e7c19704ec211b95eff7d93ce3cabdf538ad7a4 Verified, thanks! |