Progress bar appears before action confirmation

When I am deleting files or folders Dopus progress bar appears before I press Delete button to confirm the action. Screenshot below shows how it looks.

Not really a bug, since confirmations and other choices that are part of the operation the progress dialog is for will routinely show over the progress dialog.

However, the initial confirmation should normally appear before the progress dialog has even opened, unless you have turned off Preferences / File Operations / Progress Indicators / Delayed progress indicators or set it to a very low time.

I thought that it might be intended behavior but came to conclusion that I have to report it as a bug because I don't remember it working that way in previous versions. Another reason why I tagged it as bug is because I think it might be misleading for some users when progress bar representing the action progress appears before that action was confirmed or started. After all, some people might start panicking when they accidentally hit delete button and the deletion progress bar appears regardless of them confirming the action.

I tried deleting different files and folders and progress bar sometimes appears before confirmation sometimes It doesn't, there is also something wrong with the percent values that it shows during the operation.
One file. The progress bar doesn't appear before action confirmation.

Several files. The progress bar appears before action confirmation but shows strange percent values.

Several files. The progress bar appears before action confirmation and shows correct percent values.

Folder. The progress bar appears before action confirmation and shows correct percent values.

Yes, I agree and was about to include all the same screenshots - thanks, Sh1ro.

This regression or behaviour change was introduced after 12.17 stable release. It bugged me enough that I reverted my install.

Up to 12.17 stable, all "Confirm File Delete" boxes never displayed the progress box until after confirmation, as shown in the One file screenshot. With the exception when counting many files. Perfect behaviour.

Shown in the screenshot with the yellow progress bar, this indeterminate but often enough occurrence indicating that all but the final item has been deleted, is a bug in my view.

On the rare occasion, I have had the progress box display on top of the confirmation box for a brief second before retracting behind. Thus, taking window focus and thwarting my "Enter" key to execute the delete button. Frustrating and inconsistent behaviour, particularly when you are about to permanently delete files.

1 Like

How are the Delayed Progress Dialogs settings I mentioned configured on both your systems?

Try increasing the time setting.

Yes, that Delayed progress indicators setting you mentioned earlier was handy to know. Thank you.

Mine is the default setting: checked and delay at 800ms.

I tested the maximum delay setting of 10000ms (10 seconds) hoping it may be a work around. When I tried deleting many folders and files at once, it delayed the display of counting progress box. There was no indication a delete command had been executed and was in progress until 10 seconds.

So you're deletion a lot of files, where counting takes more than 10 seconds, and want the progress dialog to appear while counting, but then want it to disappear when the confirmation prompt is shown, and then for the progress dialog to reappear again after that?

The way it works, if the progress dialog has already appeared then prompts about the same operation open on top of it. I think that makes sense.

You can disable the counting before deletion if you don't want that to happen. (The confirmation prompt will display less information in that case, but will happen instantly.)

The confirmation prompt no longer halts the display of the progress dialog if it is yet to be displayed. This is changed behaviour after 12.17 stable. Causing unnecessary distraction.

If the progress dialog has already appeared, due to counting or whatever pre-delete reason, it does not need to close when eventually displaying the confirmation prompt.

If the confirmation prompt displays before the progress dialog (before the Delayed progress indicators ms delay), then halt the display of the progress dialog until delete prompt is confirmed. This is the original behaviour.

Mine are configured to the defaults.

Increasing the time or unchecking Delayed progress indicators checkbox doesn't seem to change anything, except the time that it takes for the progress bar to appear. Apart from that, Dopus behaves pretty much the same:
1)when I delete one file, then the progress bar never appears before the operation is confined
2)when I delete several files, then the progress bar always appears before the operation is confirmed with delay that is set in the settings.
3)when I delete a folder, the progress bar always appears before the operation is confirmed with delay that is set in the settings.
Another important thing is that if Delayed progress indicators checkbox is unchecked in the settings Dopus still behaves as if this option is active enforcing the delay. It uses the last set delay as delay value. In other words, if I set Delay to 2000 ms then uncheck Delayed progress indicators checkbox, Dopus will enforce the delay of 2000 ms.

That makes sense, you're right, but we are talking here about different case.
Here is how it looks:
1)I am permanently deleting(shift + del) a bunch of files.
2) Then a confirmation dialog appears and Dopus asks me if I really want to delete all these files.
3)Then before I click the Delete button, in other words before the action is confirmed, the Progress Dialog representing this specific action(deletion) appears.
And what makes it worse this behavior is inconsistent, meaning that sometimes Progress Dialog appears(several files, folder) sometimes it doesn't(one file), it can show correct progress values(0%) or incorrect progress values(85% etc).
In previous versions of Dopus Progress Dialog showing the action progress wasn't appearing before the action was confirmed.

Thank you for pointing out the exact version when this behavior have been introduced.

1 Like