Comment 9 for bug 1909729

The design here is different from the download progress, yes. The download progress has to deal with potentially long times whereas the cache unlocking only needs to wait for a number of seconds you can count (unless it's waiting indefinitely..., but even then I'd expect you'd have stopped earlier and revisited that later), its also closely related to percentage with the maximum of 120 in non-interactive cases.

I believe that for the max timeout of 120s a seconds based approach makes more sense, and arguably we need that for the interactive one for consistency too. In terms of progress, this also jumps around less.

I have not analysed this further, but I also vaguely recall some size constraints in terms of the length of the string and how it fits into standard 80 character width terminal.