Updating progress bar not full when process complete and install button enabled

[lostminds]

Summary

After updating to 2.0 I noticed a small UI issue (on macOS 12.1). As you can see in the video below, sometimes when downloading an update the progress bar will stop short of being full even when the process is finished and the "Install and relaunch"-button is enabled.

If you wait around a little it usually eventually fills up, but it still looks a little strange and should hopefully be an easy fix.

Possible Fix

In whatever code that is called when the update is ready that enables the install and relaunch button, ensure the progress bar is also set to 100% so they are in sync.

Version

2.0

Sparkle.progress.not.full.mp4

[zorgiepoo]

macOS may do some weird things these days with propagating progress changes to the user.

Still there may be a bug here. I don't think it reproduces with the test app, and this could potentially vary based on the archive if it's due to the extraction logic, so I may need a repro case or you would need to debug if the progress reaches 100% (not the UI part).

[zorgiepoo]

I see our DMG unarchiver has a bug in our tests in both 1.x and 2.x (eg testUnarchivingHFSDmgWithLicenseAgreement) where we compute total count based on number of file items available but skip non-readable items (such as .Trashes directory)

double itemsCopied = 0;
double totalItems = (double)[contents count];

for (NSString *item in contents)
{
    NSString *fromPath = [mountPoint stringByAppendingPathComponent:item];
    NSString *toPath = [[self.archivePath stringByDeletingLastPathComponent] stringByAppendingPathComponent:item];
    
    // We skip any files in the DMG which are not readable.
    if (![manager isReadableFileAtPath:fromPath]) {
        continue;
    }
    
    itemsCopied += 1.0;
    [notifier notifyProgress:0.5 + itemsCopied/(totalItems*2.0)];

    SULog(SULogLevelDefault, @"copyItemAtPath:%@ toPath:%@", fromPath, toPath);

    if (![manager copyItemAtPath:fromPath toPath:toPath error:&error])
    {
        goto reportError;
    }
}

Here at least we ought to filter out non-readable files first before computing total count to process, or just simply include non-readable items in the progress instead. testUnarchivingAPFSDMG test appears not to have any non-readable items so it doesn't have this specific issue. You might be able to work around this issue by not having non-readable items (check ls -la on your dmg volume mount)

Feel free to make a PR or else I'll get to this eventually.

[lostminds]

Yeah, that sounds like it's it since this update was delivered as a signed dmg. Good catch!

However, note that if I wait for a while longer the progress bar eventually goes up to 100%. To me the bug from a usability perspective is that the progress bar being full and the install-button enable is out of sync, they should happen at the same time to avoid sending mixed signals to the user (is it finished or not?).

[zorgiepoo]

NSProgressIndicator may have a short animation delay which is a systematic thing out of our control. Basically "works as expected". If you want to debug if this is the issue you can log out when we are setting the progress value and compare the timings to what's being done on screen.

If however the progress is never updated fully I suspect it's our bug as I noted above. Possibly also the case if it takes a really long time for the progress bar to animate fully, but that is odd.

Maybe I'm missing something else. I have created dmg's for my apps without a .Trashes directory that your archives have (using DMG Canvas in my case), so a factor here is also how the dmg is created.

[lostminds]

I just tried it on an older system running 10.15 and didn't get the same issue as on macOS 12.1. So it might be related to some long update animation thing on macOS 11+. I've noticed that there is a very long such animation on macOS 11+ when going from undetermined progress to full (the bar will bounce back and forth a couple of times before filling up, I've seen this in Disk Utility converting dmgs for example). So if at some point during the process, however brief, Sparkle is turning the bar to undetermined and back that could be a cause for the delay.

[zorgiepoo]

Yes exactly, a "feature" in progress bars in macOS 11+. If you want this changed, this is probably an OS feedback report, not a Sparkle bug report.

There is a logic bug in Sparkle with unarchiving certain dmg's however, so we'll track this issue to fixing that bug which should be a trivial change.

[zorgiepoo]

So if at some point during the process, however brief, Sparkle is turning the bar to undetermined and back that could be a cause for the delay.

Yeah, it's very possible Sparkle is switching back and forth for indeterminate and determinate (due to the nature of the active task). I'm not sure this is avoidable though (or it could just more generally be going from full progress -> back to 0). I can also see the same behavior with 1.x btw (but timings may vary from run to run)

[zorgiepoo]

I'm seeing that we have a short-lived indeterminate "installing" state after extraction (determinate) and before allowing the user to install/relaunch the app (determinate at full progress), but this looks unnecessary at this point (it should only be occurring after the user hits relaunch and is not doing anything interesting before then), so I think removing/relocating this state may improve this issue as much as we can. If the progress for downloading or extraction is not steady you may still see some sort of "jump" (and DMG extraction progress state is definitely worse than our unarchiver for other formats).

[zorgiepoo]

I think the behavior for this should be a little bit better in 2.1.0-beta.1 now.