NSIS uninstall window hidden by install window

[Daniel Beardsmore]

I had 0.92.1 installed (allegedly, according to the installer, since the text line spacing bug it claimed to fix was still there) and the 0.92.2 installer prompted for me to uninstall it prior to installing 0.92.2, which I acknowledged as usual.

It then proceeded to start installing 0.92.2 for a while, and it seemed to be taking its time. I went to check up on it, and then noticed that the uninstaller for 0.92.1 was open in the background, and sat on the start page with Next active (i.e. it had yet to even start uninstalling).

I'm not sure what the sequence was, but of the two programs (installer and uninstaller), the uninstaller was first in the taskbar, so the installer seemed to have closed its window, opened the uninstaller, which didn't get anywhere (waiting for the user) and then opened a new installation window and proceeded to install regardless. The installer window had never come to the front, so I missed it until I spotted a stray icon in the taskbar.

This may be why, at the following stage, it's chewing up a whole CPU core and slowly wandering through the program's folder tree getting nowhere (since it's not expecting the program to be already installed):

Search in: C:\Program Files\Inkscape\<slowly making its way through the tree>
...
Output folder: C:\Program Files\Inkscape\lib\python2.7
Output folder: C:\Program Files\Inkscape

Waiting for it to complete here -- it's not actually giving any indication in the progress panel as to what exactly it's trying to do here. Examination with Process Monitor shows that it is obsessing over C:\Program Files\Inkscape\Uninstall.dat -- it seems to be devouring Uninstall.dat before processing each Python file, checking each file ("NOT A DIRECTORY") and then writing something into exclude.tmp, which I can't open as I assume it's locked by the installer process.

This is Windows 10 Pro Creators Update 64-bit, and the 64-bit .exe installer for Inkscape.

[Daniel Beardsmore (telcontar)]

I used PowerShell to delete all the files from the program directory while the installer was running (all except the locked uninstall log), and that knocked sense into it and got it to complete.

I've now run the installer again (0.92.2 installed albeit with most of the files missing, and 0.92.2 replacing it) -- screenshot attached. (This also rules out 0.92.1/.2 incompatibility as the same fault occurs with the 0.92.2 installer talking to its own uninstaller.)

Command line for the uninstaller:

"C:\Users\$me\AppData\Local\Temp\~nsuA.tmp\Un_A.exe" _?=C:\Program Files\Inkscape\

Reinstallation has succeeded following a successful prior installation.

[Patrick Storz (ede123)]

I just confirmed on my system that the uninstaller window is positioned *in front* of the installer window by default (as is the intended and designed behavior).

If that is not the case for you it's likely due to software / configuration settings specific to your system.
Could you please check if there is any interfering software? (For example I noticed a non-standard button in the task bar of the windows in your screenshot).

Regarding the issue with the installation being slow I opened bug #1718275. It only happens if Inkscape was not uninstalled before and might be an issue with the program we use for creating installers (NSIS).

[Daniel Beardsmore (telcontar)]

I realised that this is what you were trying to do, but in reality it's not what happens. On the third attempt (while trying to track an unrelated bug) it worked, while on the previous attempt I clearly saw the windows display in the wrong order. On the first attempt I was completely oblivious to the first window for ages.

Windows is very aggressive in recent versions (8 and 10 especially) about blocking programs from opening windows on top of your active window, and although this tends to result in the offending window flashing orange in the taskbar, it does not always. Opening two live, active, attention-seeking windows simultaneously is terrible UI even if it did work.

In almost all software that follows this general design, the uninstaller is invoked to run automatically (shown visibly but completes and closes automatically). In Inkscape's case, it's deliberately choosing not to auto-start the uninstallation (which is very strange, considering that I've already had to accept a prompt asking me to agree to uninstallation) *AND* opening two windows at once that simultaneously expect to be used (just plain wrong) *AND* failing to make any attempt to wait for the child process to complete.

This is asking for trouble and it's causing trouble.

[Patrick Storz (ede123)]

I'm on Windows 10 myself and it plays nice, so maybe I taught my OS better manners than you did ;-)

If the user decides to uninstall the old version we simply call the uninstaller of the old version for them, which might not be the nicest solution but usually works.

Hyperbole aside, I agree it is not an ideal solution and we might streamline uninstallation of the previous version a bit in future (especially as remnants from previous versions caused some trouble in the past and seeing that re-installing without uninstalling the previous version is actually a lot slower).
However the only "automatic" option would be to uninstall the old version automatically without showing any window at all (also no progress bar!) and wait for the un-installation to finish before allowing the user to continue with installation, which is not exactly great UI either...

[Daniel Beardsmore (telcontar)]

Even Windows 7 has confusing and erratic handling of moving new windows into the background when the GUI thinks they would obstruct your work (and it's not just me — it's a fundamental problem with Windows as a graphical interface).

It's no use writing a bad program and hoping it works — you have to start with a good program. It sounds like the installer runtime itself is defective if it can't get something this simple right -- this is a basic use case for an installer!

For starters, if you're calling a child process, wait for it to terminate. You're opening two modal dialogs simultaneously and there are various ways that either one could be subject to lag and could get switched, and there's nothing to indicate to the user that they're supposed to ignore the wrong one if the windows get reversed. The whole premise is wrong from the start. If the parent window must exist at all (as some kind of safety net) then should say "Waiting for uninstallation to complete", and then wait on the child PID until that process terminates, and then commence the installation wizard. If NSIS can't handle a basic upgrade after all these years, then maybe it's time to replace it. (As I recall, the MSI package for Inkscape can't upgrade at all -- are we living in the past?)

In my case, the windows clearly opened in the wrong order as the taskbar buttons were reversed, so there was some kind of lag. Could be AV, could be paging, could be absolutely anything. You have to start with giving the computer sensible instructions and work up from there.

[Daniel Beardsmore (telcontar)]

Repeat occurrence on a different computer in Windows 10 1709 64-bit, 64-bit Inkscape.

No active window tracking. No UltraMon. Nothing that would interfere with window display order.

By the time I'd realised the problem, the installer was already stuffed up. In the end (after killing the installer twice) I had to wipe C:\Program Files\Inkscape and start over.

[Patrick Storz (ede123)]

Closing in favor of https://gitlab.com/inkscape/inkscape/issues/300