Windows 7 taskbar does not show scanning indeterminate progress when the download manager window is closed

RESOLVED FIXED in mozilla12

Status

()

defect
RESOLVED FIXED
8 years ago
8 years ago

People

(Reporter: jimm, Assigned: jimm)

Tracking

(Blocks 1 bug)

Trunk
mozilla12
x86_64
Windows 7
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

STR:

1) navigate to the location of a big file (a try server build zip is good)
2) open the download manager window, place it neat the fx taskbar icon
3) right-click, save as file to begin download

Note, when the download reaches the scanning phase, both the taskbar progress and the download manager progress go into an indeterminate progress state.

4) delete the file and close the download manager window
5) right-click, save the file again, and watch the taskbar progress
6) Once the download completes, the progress shuts down, and few seconds later after the scan completes, the download popup will appear.

(You can also close the download manager window during the scan to see this bug, the indeterminate state will shut down on the taskbar once the window is closed.)

This is a pretty bad bug since if the user closes fx before the download completes the downloaded file will be deleted. We need the visual "scanning" indicator up on the desktop so users know the download isn't finished yet.
Posted patch fixSplinter Review
Sid, thought I'd ask you to do a review of this since you're the most familiar with this code. This appears to be a pretty harmless change that addresses this bug.
Assignee: nobody → jmathies
Attachment #587411 - Flags: review?(sagarwal)
IIRC, it was a conscious decision to only show the "simple" progress for the browser window, and show detailed progress if the DM is open.

I think it's more of a bug in the DM if the file is deleted even after it has completed the download and is in scanning state, but I agree that this change is harmless and would improve the situation.

The comment above the code being changed will need to be updated to reflect this change.
(In reply to Felipe Gomes (:felipe) from comment #2)
> IIRC, it was a conscious decision to only show the "simple" progress for the
> browser window, and show detailed progress if the DM is open.
> 
> I think it's more of a bug in the DM if the file is deleted even after it
> has completed the download and is in scanning state, but I agree that this
> change is harmless and would improve the situation.

As a user, I want the scan to finish, and I'd like visual indication that it is taking place / completed. My guess is most users never open the download window on Win7, they just look at the taskbar for status. (I'm basing that on my own behavior - I haven't had to open the dl window in ages, the taskbar is all I need.)

I agree the file probably shouldn't be deleted, maybe locked or hidden, not sure. This is a more complex problem that should be filed in a follow up bug.
Blocks: 717201
Attachment #587411 - Flags: review?(sagarwal) → review?(felipc)
This STATE_INDETERMINATE represents both a scanning file or a download of unknown size. Both cases are treated the same here: http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/downloads/DownloadTaskbarProgress.jsm#319

do you think we should be conservative and only display this for scanning files (if DM is closed)? Or it doesn't matter much?
Comment on attachment 587411 [details] [diff] [review]
fix

Not sure if my review can count here, but the change is simple and straightforward.

Need to update the comment above to reflect reality.
Attachment #587411 - Flags: review?(felipc) → review+
I mean the source code comment above the 'if' being changed
updated comments per felipe's feedback.

https://hg.mozilla.org/integration/mozilla-inbound/rev/9b2f2f924253
https://hg.mozilla.org/mozilla-central/rev/9b2f2f924253
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla12
Sorry about getting to this late -- I wasn't available Thursday onwards. Yes, I agree that the underlying problem in bug 717201 should also be fixed.
You need to log in before you can comment on or make changes to this bug.