1. Install the latest build of the extension (tested with 3/1)
2. Go to apps.mozillalabs.com/appdir
3. Install an app natively
4. Launch the app natively
5. Uninstall the native app
An error should be reported indicating that the app cannot be uninstalled, as the app is currently running.
The app is successfully uninstalled, even though the app is actively running. The app can be used natively after being uninstalled.
Seen so far on Win 7/XP.
This works on Mac OS X. Therefore, this is a Windows-specific issue. Assigning to Tim.
This should be fixed and verified in the mozilla-central implementation.
If you run the webapp uninstaller while the app is running, you should now notice that all the files you expect to disappear in fact disappear. Under the hood, we're moving the file (which you can do even while the file is running). Since we're not removing profile data during uninstall (bug 710790), the app can continue running for as long as the user wants it to. When the app is closed, the uninstall is effectively complete.
Steps (same as above)
The app should be uninstalled (all files that are typically removed during the uninstall process are removed)
This should be working on builds from the github repo as of this commit: https://github.com/michaelrhanson/mozilla-central/commit/c681630a3c85d26577cfbfcf6f6058845551190c
Why are we allowing an uninstall to occur in the first place with the app already running though? Typically with native applications, I believe this is not allowed (correct me if I'm mistaken). That's what this bug talks about. I believe the OS X implementation on the extension originally did implement this correctly, windows did not.
(In reply to Jason Smith from comment #4)
> Why are we allowing an uninstall to occur in the first place with the app
> already running though? Typically with native applications, I believe this
> is not allowed (correct me if I'm mistaken). That's what this bug talks
You're correct that this is typically not allowed, but that's probably because most native applications need the app to be closed before uninstallation can succeed. We can uninstall successfully even while the app is running, which can be an advantage for us in certain situations. If the executable is running but the user doesn't realize that it is running (e.g. the user doesn't know how to close the app, or the stub experiences something like bug 401301), we can still allow the user to uninstall the app. When the machine is rebooted, the uninstallation is effectively completed.
Additionally, blocking the uninstallation if the EXE is in use adds complexity (and at least one localization string) to the uninstaller. The mechanism that Firefox uses to determine if an instance is running is not available to us, and the uninstaller is incapable of telling the difference between "file could not be deleted because it is in use" and "file could not be deleted because of insufficient privileges"
Okay, makes sense. Agreed. I'll update my test cases to reflect this.
This should no longer be an issue: If you uninstall an app while it is running, the executable should still go away.
This works, but causes a regression in the process. See the screenshot. If I uninstall the application while it's running from the uninstaller in the %APPDATA%, then i will get an error reported saying that the program might not have been installed correctly. The uninstall ends up being successful still, but a false warning is sent to the user. Request to reopen, or should we track this in a separate bug?
Created attachment 620914 [details]
Error On Uninstall Through Uninstaller
(In reply to Jason Smith [:jsmith] from comment #8)
> This works, but causes a regression in the process. See the screenshot. If I
> uninstall the application while it's running from the uninstaller in the
> %APPDATA%, then i will get an error reported saying that the program might
> not have been installed correctly. The uninstall ends up being successful
> still, but a false warning is sent to the user. Request to reopen, or should
> we track this in a separate bug?
Filed a separate bug to track this issue. Marking as verified then.