Bug 405020

Summary: Checking for updates delays software install and password prompt...
Product: [Applications] Discover Reporter: Eric Malamisura <eric.malamisura>
Component: discoverAssignee: Dan Leinir Turthra Jensen <leinir>
Status: RESOLVED DUPLICATE    
Severity: normal CC: admin, aleixpol, nate
Priority: NOR    
Version: 5.15.2   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Eric Malamisura 2019-03-03 04:42:50 UTC
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
Comment 1 Dan Leinir Turthra Jensen 2019-03-04 10:16:12 UTC
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.
Comment 2 Nate Graham 2019-03-08 00:08:20 UTC

*** This bug has been marked as a duplicate of bug 402928 ***