| Summary: | When there's more than one Kickoff, clicking on the old one causes search to be broken until you search with the new one | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | Claudio <holo-doc> |
| Component: | Application Launcher (Kickoff) | Assignee: | David Edmundson <kde> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | alkl58, auxsvr, colin, detzi88, ecc_2000, federico, freakinfedorafreak, heeen, ieknight1101, joshua.nestler, kde, Kicer86, lestofante88, maltejur, mickael9, mikel5764, nate, nlynzaad, noahadvs, petersearby, phissica, plasma-bugs, postix, rarp, safa1996alfulaij, sam, sephiroth_pk, victor.itkin, wguerrero42 |
| Priority: | VHI | Keywords: | regression |
| Version: | 5.22.90 | ||
| Target Milestone: | 1.0 | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/plasma/plasma-desktop/commit/a609b639a3aa2493d1db3922fb7d733733d97c20 | Version Fixed In: | 5.23.5 |
| Sentry Crash Report: | |||
|
Description
Claudio
2021-09-29 18:59:44 UTC
Can reproduce, but with the following quirk: once I search once with the newly-added Kickoff, it starts working with the old one. This bug also appeared for me after updating to 5.23.1. On my three monitor setup, only one Kickoff works correctly (not my primary monitor though...). What I noticed is that when I search in the working Kickoff applet, the others sometimes display its search results. They also do not allow me to enter text into the search box just by typing with an open Kickoff, requiring me to click the search box first. Operating System: EndeavourOS KDE Plasma Version: 5.23.1 KDE Frameworks Version: 5.87.0 Qt Version: 5.15.2 Kernel Version: 5.14.12-arch1-1 (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-6700 CPU @ 3.40GHz Memory: 15.6 GiB of RAM Graphics Processor: AMD Radeon ™ R9 380 Series *** Bug 444040 has been marked as a duplicate of this bug. *** I'm facing the same issue with plasmashell 5.23.1 and a dual display setup. I have "solved" the issue using the "Application Launcher" widget on the laptop and "Application Dashboard" on the external display. I think this might be somehow related to the keyboard shortcut feature since when I tried to delete both the Launchers, when I tried to assign the Alt-F1 shortcut to both of them I was forced to override the previous assignation. I'm not sure but this was not the case before this update, as far as I recall. Federico *** Bug 444934 has been marked as a duplicate of this bug. *** Noah, can you take a look into this? It seems to be a regression in 5.23. (In reply to Nate Graham from comment #6) > Noah, can you take a look into this? It seems to be a regression in 5.23. yes, I was planning to. I wonder if each instance of Kickoff shares the same singleton, but not the same models? Hi, I did a fairly detailed comment on issue 444132 that seems to be a duplicate of this. Don't know enough of QT development to say for sure but from the testing it definitely seems to be sharing the same singleton. *** Bug 445371 has been marked as a duplicate of this bug. *** *** Bug 444132 has been marked as a duplicate of this bug. *** Maybe this info might help identifying the issue: Downgrading the Kickoff menu by placing an older version inside "~/.local/share/plasma/plasmoids/" solves the issue. See my Comment on Manjaro Forum: https://forum.manjaro.org/t/no-search-results-in-application-launcher/91500/6 I am not sure how the system works, however I have two theories: 1. The regression only happened in the kickoff applet 2. The regression is somewhere else and using a "custom" (in this case "older") applet uses a different api(?) interface (which I doubt) *** Bug 445910 has been marked as a duplicate of this bug. *** After testing different Git versions, I can confirm that the regression happened in https://invent.kde.org/plasma/plasma-desktop/-/commit/9d9c4f169ed424e976636a6d5fa23c7a1e40576b So far the only obvious error message I see is: "file:///usr/share/plasma/plasmoids/org.kde.plasma.kickoff/contents/ui/ApplicationsPage.qml:118: TypeError: Cannot read property 'forceActiveFocus' of null" I can reproduce this on Operating System: Kubuntu 21.10 KDE Plasma Version: 5.23.4 KDE Frameworks Version: 5.88.0 Qt Version: 5.15.2 Kernel Version: 5.13.0-21-lowlatency (64-bit) Graphics Platform: X11 Processors: 32 × AMD Ryzen Threadripper 1950X 16-Core Processor Memory: 62.7 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 2080/PCIe/SSE2 I can reproduce this as well. On my dual monitor setup, I worked around it by removing the complete control panel from the 2nd monitor and adding a new, blank panel which I populated with the desired widgets, sans kickoff. Simply removing kickoff from the 2nd monitor didn't have any effect. Operating System: Manjaro Linux KDE Plasma Version: 5.23.3 KDE Frameworks Version: 5.88.0 Qt Version: 5.15.2 Kernel Version: 5.15.2-2-MANJARO (64-bit) Graphics Platform: X11 Processors: 12 × AMD Ryzen 5 3600 6-Core Processor Memory: 31.3 GiB of RAM Graphics Processor: AMD Radeon RX 6600 XT *** Bug 446310 has been marked as a duplicate of this bug. *** Can the person who identified the commit please remove: `pragma Singleton` from ActionMenu.qml and confirm that it now behaves as expected. (In reply to David Edmundson from comment #17) > Can the person who identified the commit please remove: > > `pragma Singleton` > from ActionMenu.qml and confirm that it now behaves as expected. Changing that on the Plasmoid shipped with my Distro, the plasmashell refuses to load (kstart5 plasmashell) with the message: "QQmlComponent: Component is not ready" Additionally I tested the latest git version as of writing (placed it under local/share...) with the same broken search behavior, as well removing the line caused in plasmashell not starting. However, if I delete the line and remove / add the applet manually, it will show the launcher, however the same broken search issue exists. The easiest way to tell if it's broken: 1. Remove any other Kick off Applet. 2. Add two Kickoff Applets to the Taskbar. 3. Start searching with the first one, by clicking on the icon and start typing (results show as expected), close it by clicking somewhere else. 4. Start searching with the second one, by clicking on the icon and start typing (results show as expected), close it by clicking somewhere else. 5. Try to search with the first applet, by clicking on the icon and start typing. No Results will show. Opening the second applet, you will see the just typed stuff from the first applet. The first applet now also won't display anything from the search, even if the text is cleared from the second kickoff applet. Note that I am not familiar with how Qt / Singletons work, however coming from a developers perspective I can roughly tell what's happening by observing the behavior. (So take the following with a grain of salt) The current behavior from the Application Launcher is to bind the search item to the content area. For this, user input (keyboard) is being delegated to that search item and search result content is being displayed. Adding a second Application Launcher, which is a different object, now maybe restores the binding between itself and the existing search item from the first Application Launcher. Now user input from the first Application Launcher seems to be delegated to the search item, which is now bound to the second Application Launcher. This results in the observed behavior, that writing something in the first Application Launcher is not seen there, yet visible in the second Application Launcher. The search object is not bound to the first launcher anymore, that's why we see the message: "ApplicationsPage.qml:118: TypeError: Cannot read property 'forceActiveFocus' of null". It could also be, that it's some issue with the search bar in Header.qml or it could be that only one global searchView is being created. Of course, this can be all wrong, but I think it might be something related. Sorry for the wall of text. A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/744 (In reply to Bug Janitor Service from comment #20) > A possibly relevant merge request was started @ > https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/744 Seems to fix the issue - can confirm working. Thank you very much @Noah Davis! Git commit cbef8e66fb7b7bad82b245d49849df6b0552d9aa by Nate Graham, on behalf of Noah Davis. Committed on 13/12/2021 at 20:48. Pushed by ngraham into branch 'master'. Move plasmoid specific properties out of singleton M +7 -4 applets/kickoff/package/contents/ui/ActionMenu.qml M +7 -7 applets/kickoff/package/contents/ui/ApplicationsPage.qml M +5 -5 applets/kickoff/package/contents/ui/BasePage.qml M +6 -6 applets/kickoff/package/contents/ui/Footer.qml M +9 -74 applets/kickoff/package/contents/ui/FullRepresentation.qml M +14 -14 applets/kickoff/package/contents/ui/Header.qml M +105 -33 applets/kickoff/package/contents/ui/Kickoff.qml M +1 -0 applets/kickoff/package/contents/ui/KickoffItemDelegate.qml M +2 -44 applets/kickoff/package/contents/ui/KickoffSingleton.qml M +2 -2 applets/kickoff/package/contents/ui/LeaveButtons.qml M +3 -3 applets/kickoff/package/contents/ui/NormalPage.qml M +5 -5 applets/kickoff/package/contents/ui/PlacesPage.qml https://invent.kde.org/plasma/plasma-desktop/commit/cbef8e66fb7b7bad82b245d49849df6b0552d9aa Git commit a609b639a3aa2493d1db3922fb7d733733d97c20 by Nate Graham, on behalf of Noah Davis. Committed on 13/12/2021 at 20:54. Pushed by ngraham into branch 'Plasma/5.23'. Move plasmoid specific properties out of singleton (cherry picked from commit cbef8e66fb7b7bad82b245d49849df6b0552d9aa) M +7 -4 applets/kickoff/package/contents/ui/ActionMenu.qml M +7 -7 applets/kickoff/package/contents/ui/ApplicationsPage.qml M +5 -5 applets/kickoff/package/contents/ui/BasePage.qml M +6 -6 applets/kickoff/package/contents/ui/Footer.qml M +9 -74 applets/kickoff/package/contents/ui/FullRepresentation.qml M +14 -14 applets/kickoff/package/contents/ui/Header.qml M +105 -33 applets/kickoff/package/contents/ui/Kickoff.qml M +1 -0 applets/kickoff/package/contents/ui/KickoffItemDelegate.qml M +2 -44 applets/kickoff/package/contents/ui/KickoffSingleton.qml M +2 -2 applets/kickoff/package/contents/ui/LeaveButtons.qml M +3 -3 applets/kickoff/package/contents/ui/NormalPage.qml M +5 -5 applets/kickoff/package/contents/ui/PlacesPage.qml https://invent.kde.org/plasma/plasma-desktop/commit/a609b639a3aa2493d1db3922fb7d733733d97c20 *** Bug 446871 has been marked as a duplicate of this bug. *** *** Bug 446983 has been marked as a duplicate of this bug. *** This is my first time going through the bug report process here. I see it was merged, but I was wondering if there's any way to track which release it will be in. If it's too complicated/not worth the time to explain, that's fine. I'm mainly just curious how it works. (In reply to Colin Gauvin from comment #26) > ... but I was wondering if there's any way to track which release it will be in. You can look at the top right of the overview of the Bug report, you will see "Version Fixed In", which is 5.23.5 for this bug report. The Schedule of the Plasma 5 releases can be found here: https://community.kde.org/Schedules/Plasma_5#Future_releases Plasma 5.23.5 is scheduled for Tue 2022-01-04 - however until it lands in your Distro can take a few days to months depending on the Distros release cycle. (In reply to alkl58 from comment #27) > (In reply to Colin Gauvin from comment #26) > > ... but I was wondering if there's any way to track which release it will be in. > > You can look at the top right of the overview of the Bug report, you will > see "Version Fixed In", which is 5.23.5 for this bug report. > > The Schedule of the Plasma 5 releases can be found here: > https://community.kde.org/Schedules/Plasma_5#Future_releases > > Plasma 5.23.5 is scheduled for Tue 2022-01-04 - however until it lands in > your Distro can take a few days to months depending on the Distros release > cycle. Awesome, thanks so much. *** Bug 447313 has been marked as a duplicate of this bug. *** *** Bug 447262 has been marked as a duplicate of this bug. *** *** Bug 448640 has been marked as a duplicate of this bug. *** |