Window controls stop working after an error popup appears

[Bob-A-Dook]

When an error occurs during package installation, a popup with its description appears.
After I close the popup, the controls of the main Captain window become unresponsive to mouse clicks. I can't minimize, maximize or close it by clicking; shortcuts such as Alt+F4 or right-clicking the bottom bar and selecting Close still work, though.

Tested on Linux Mint MATE 22.2 in live USB mode.

Steps to reproduce:

• Get a .deb file which would cause an error on installation attempt (I think the error type does not matter. I personally get a file which would require downloading dependencies, then turn off Wi-Fi before clicking);
• Double-click the file to get Captain to open - all window controls work normally when clicked;
• Click Install Package and wait until the error popup appears;
• After the popup is closed in any way, the main window controls no longer respond to mouse clicks.

[schorschii]

I have this issue too in a different case: some packages (e.g. OCO-Agent) ask for input when installing. The window e.g. for text input opens and let you type your values and correctly closes after clicking "Next". The package is then successfully installed but the main window of Captain is unresponsive and cannot be closed normally.

[Bob-A-Dook]

Looks like there's an easy fix for the window controls issue :) The solution is inside the function called on_install_finished.

Window controls are restored by calling ui_window.set_sensitive(True). Currently, this is only called if all conditions of a successful installation are met (package name in cache + marked as installed + same version as current package):

if self.deb.pkgname in cache:
    pkg = cache[self.deb.pkgname]
    if pkg.is_installed:
        if str(pkg.installed.version) == str(self.version):
            #...
            self.ui_window.set_sensitive(True)

The solution is to dedent this last function call, so that it's called in all cases:

if self.deb.pkgname in cache:
    #...
self.ui_window.set_sensitive(True)

[Bob-A-Dook]

@schorschii, I also tested this with your .deb file and the window was responsive after the change. There's another issue remaining, though.

Captain's code hits the "no-success path" when handling your package (even when it's successfully installed), because the line

if self.deb.pkgname in cache:

evaluates to False.

That's because the value of self.deb.pkgname is OCO-Agent, while the cache object only has a lowercase entry oco-agent after installation:

<Package: name:'oco-agent' architecture='amd64' id:166258>

Looks like there might be a mismatch between how Captain and APT normalize your package's name. As a result, Captain doesn't find your package in cache and doesn't consider it fully installed.

This leads to two side effects:

• there is no "OCO-Agent is now installed" message after the installation finishes,

• the Install Package button stays green and clickable after the installation, even if you close and reopen the DEB file.

  (APT rightfully considers the package installed, though, so the text inputs you mentioned don't appear again if you actually click this button).

[schorschii]

Thanks for fixing this and the hint about the uppercase package name. I admit that using uppercase package names is very rare, but it would be good if Captain handles this in the same way like apt does. Should I open a separate issue for that?

[Bob-A-Dook]

Glad to help! :) I'm just a hobbyist Mint user, so I can't speak for the maintainers, but a separate issue about cache and package name handling sounds nice. It's more general and internals-related than the one here.
And I definitely agree that Captain should match apt's behavior.