SUMMARY When installing software from a .deb package for example, and Discover is completely fresh and closed when it opens the Install button is enabled and available to click. When you click it however it does nothing. At first glance it's difficult to understand what's going on, after some investigation I have figured out that if Discover is Checking for Updates clicking Install does nothing as it gets queued up but there is no indication. Additionally, since it needs administrative access it doesn't ask for your password until Check Updates is finished either. If you click Install multiple times, it will break it and you may never see the password prompt ever again until you terminate the process. STEPS TO REPRODUCE 1. Install .deb package while Discover is cold and closed and in a state that will force it to run a check for updates on startup. 2. Discover will be busy checking for updates, while it is, click "Install" 3. No action occurs, password prompt is delayed until Check Updates is done. OBSERVED RESULT No action occurs. EXPECTED RESULT Immediately ask for password so the app install can done in the background as normal after check updates is done. Disable Install button while its queued up for install. SOFTWARE/OS VERSIONS Windows: MacOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
As much as i like the idea of the application getting out of the way, i'm not sure i see a way of doing this that doesn't involve storing the password in memory for a while, which... seems like a concept with which our more security conscious people would be terribly displeased. Perhaps a different approach might be to solve the core issue, which is that Discover checks for updates (and blocks your other operations) on startup, regardless of how that launch occurred. If that update check did not occur when you launch Discover with some parameter to show a specific application (either from a .deb, .rpm, an appstream link or anything else like that), then you would not suddenly have to wait for a potentially long running update check.
*** This bug has been marked as a duplicate of bug 402928 ***