Have download progress in Finder
Categories
(Firefox :: Downloads Panel, defect, P3)
Tracking
()
People
(Reporter: thomas, Assigned: christoph-wa)
References
Details
Attachments
(10 files, 1 obsolete file)
37.91 KB,
image/png
|
Details | |
19.76 KB,
image/png
|
Details | |
113.50 KB,
image/png
|
Details | |
64.35 KB,
image/png
|
Details | |
33.44 KB,
image/png
|
Details | |
401.87 KB,
image/png
|
Details | |
91.61 KB,
image/png
|
Details | |
1.33 KB,
text/x-troff-mm
|
Details | |
12.36 KB,
patch
|
Details | Diff | Splinter Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review |
Chrome and Safari have download progress in Finder in Mac OS X
Reference bug number in Chrome http://code.google.com/p/chromium/issues/detail?id=138962 http://code.google.com/p/chromium/issues/detail?id=139027
Comment 6•8 years ago
|
||
According to bug 548763 we do this on 10.8.
Comment 7•8 years ago
|
||
Actually, it's at least 10.7+. I'm not sure about 10.6.
Comment 8•8 years ago
|
||
Oh, Finder, not Dock. Nevermind.
Comment 9•8 years ago
|
||
I think this is a dupe of #825536. The progress bars both for the icon of the downloading file in the Dock, and in the Finder, seem to both use the same NSProgress mechanism. Unfortunately NSProgress is only 10.7+, and we still support 10.6 and likely will for some time longer. I believe NSProgress is also a private API, though maybe that has changed on 10.8 or 10.9. Not saying we could't implement it anyway.
Comment 10•6 years ago
|
||
NSProgress is public on 10.9+: https://developer.apple.com/library/mac/documentation/Foundation/Reference/NSProgress_Class/ . The method "publish", which makes the progress appear in the Dock icon, seems to be undocumented. But it's in the header, marked as 10.9 and later.
Reporter | ||
Comment 11•6 years ago
|
||
Reporter | ||
Comment 12•6 years ago
|
||
Reporter | ||
Comment 13•6 years ago
|
||
The proof of concept code gcc poc.mm -g -m64 -framework Cocoa touch /Users/thomas/Downloads/firefox-43.0a1.en-US.mac.dmg ./a.out
Assignee | ||
Comment 14•2 years ago
|
||
Comment 15•2 years ago
|
||
It is frustrating that several times I have clicked the downloading file because there is no indication of it is incomplete.
Also creating a document with the final name at the start is a mistake. Chrome creates a ".crdownload" and Safari ".download" file before it is complete.
Assignee | ||
Comment 16•2 years ago
|
||
Show download progress in the MacOS Finder
Assignee | ||
Comment 17•2 years ago
|
||
Show download progress in the MacOS Finder
Updated•2 years ago
|
Updated•2 years ago
|
Comment 19•2 years ago
|
||
Stephen, it's been while since Christoph requested review for this bug and I think it'd a shame to let this great feature go to waste... can you find the time somewhere to review and/ or provide feedback? Maybe direct the review request to someone else with a more friendly looking schedule?
Thanks!!
Comment 20•2 years ago
|
||
(In reply to Mike de Boer [:mikedeboer] from comment #19)
Stephen, it's been while since Christoph requested review for this bug and I think it'd a shame to let this great feature go to waste... can you find the time somewhere to review and/ or provide feedback? Maybe direct the review request to someone else with a more friendly looking schedule?
Thanks!!
I've been looking at it. :-) Stay tuned.
Comment 21•2 years ago
|
||
Pushed by mak77@bonardo.net: https://hg.mozilla.org/integration/autoland/rev/5f48ef706159 Show download progress in the MacOS Finder r=spohl,mak
Comment 22•2 years ago
|
||
bugherder |
Comment 23•2 years ago
|
||
Backed out changeset 5f48ef706159 (bug 909760) for leakcheck permafailures during browser_windowactivation.js a=backout
Backout link: https://hg.mozilla.org/mozilla-central/rev/51d26396dfafa7b5f45acc6c8c5f1dcf93bec486
Log link: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=252112234&repo=autoland&lineNumber=14987
Log snippet:
17:38:05 INFO - nsTraceRefcnt::DumpStatistics: 2430 entries
17:38:05 INFO - TEST-INFO | leakcheck | default leaked 1 BackstagePass
17:38:05 INFO - TEST-INFO | leakcheck | default leaked 2 XPCNativeInterface
17:38:05 INFO - TEST-INFO | leakcheck | default leaked 2 XPCNativeMember
17:38:05 INFO - TEST-INFO | leakcheck | default leaked 2 XPCNativeSet
17:38:05 INFO - TEST-INFO | leakcheck | default leaked 2 XPCWrappedNative
17:38:05 INFO - TEST-INFO | leakcheck | default leaked 1 XPCWrappedNativeProto
17:38:05 INFO - TEST-INFO | leakcheck | default leaked 2 XPCWrappedNativeTearOff
17:38:05 INFO - TEST-INFO | leakcheck | default leaked 1 nsJSPrincipals
17:38:05 INFO - TEST-INFO | leakcheck | default leaked 1 nsMacFinderProgress
17:38:05 INFO - TEST-INFO | leakcheck | default leaked 4 nsMainThreadPtrHolder<T>
17:38:05 INFO - TEST-INFO | leakcheck | default leaked 1 nsTArray_base
17:38:05 INFO - TEST-INFO | leakcheck | default leaked 4 nsXPCWrappedJS
17:38:05 INFO - TEST-UNEXPECTED-FAIL | leakcheck | default 1304 bytes leaked (BackstagePass, XPCNativeInterface, XPCNativeMember, XPCNativeSet, XPCWrappedNative, ...)
17:38:05 INFO -
17:38:05 INFO - leakcheck | Processing leak log file /var/folders/57/lk2856jd42x77yvfqks88hph00000x/T/tmpR6uhCG.mozrunner/runtests_leaks_tab_pid3254.log
17:38:05 INFO -
17:38:05 INFO - == BloatView: ALL (cumulative) LEAK AND BLOAT STATISTICS, tab process 3254
17:38:05 INFO -
17:38:05 INFO - |<----------------Class--------------->|<-----Bytes------>|<----Objects---->|
17:38:05 INFO - | | Per-Inst Leaked| Total Rem|
17:38:05 INFO - 0 |TOTAL | 37 0| 123530 0|
17:38:05 INFO -
17:38:05 INFO - nsTraceRefcnt::DumpStatistics: 809 entries
17:38:05 INFO - TEST-PASS | leakcheck | tab no leaks detected!
17:38:05 INFO - leakcheck | Processing leak log file /var/folders/57/lk2856jd42x77yvfqks88hph00000x/T/tmpR6uhCG.mozrunner/runtests_leaks_tab_pid3255.log
17:38:05 INFO - ==> process 3255 will purposefully crash
17:38:05 INFO - TEST-INFO | leakcheck | tab deliberate crash and thus no leak log
17:38:05 INFO - leakcheck | Processing leak log file /var/folders/57/lk2856jd42x77yvfqks88hph00000x/T/tmpR6uhCG.mozrunner/runtests_leaks_tab_pid3256.log
17:38:05 INFO -
17:38:05 INFO - == BloatView: ALL (cumulative) LEAK AND BLOAT STATISTICS, tab process 3256
Assignee | ||
Comment 24•2 years ago
|
||
The test which causes the leak is browser/base/content/test/general/browser_contentAltClick.js
.
In the test the download is first removed from the download list and then finalized.
Normally the download is first finalized and then removed from the list.
In the updated revision I implemented the handling of download list removals, which occurs in this test.
Comment 25•2 years ago
|
||
Pushed by mak77@bonardo.net: https://hg.mozilla.org/integration/autoland/rev/8287c3d0c106 Show download progress in the MacOS Finder r=spohl,mak
Comment 26•2 years ago
|
||
bugherder |
Comment 28•2 years ago
|
||
Stephen, is that something we want to mention in our release notes?
Comment 29•2 years ago
|
||
(In reply to Pascal Chevrel:pascalc from comment #28)
Stephen, is that something we want to mention in our release notes?
Yes, I think we could. Let me know if I should propose text for the release notes. Even more importantly, if there's attribution, we should definitely give Christoph a shout out.
Comment 30•2 years ago
|
||
(In reply to Stephen A Pohl [:spohl] from comment #29)
(In reply to Pascal Chevrel:pascalc from comment #28)
Stephen, is that something we want to mention in our release notes?
Yes, I think we could. Let me know if I should propose text for the release notes. Even more importantly, if there's attribution, we should definitely give Christoph a shout out.
You can ask for the release note in Bugzilla (here are instructions: https://wiki.mozilla.org/Release_Management/Release_Notes#How_to_nominate_a_bug_for_release_notes_addition.3F). A proposal for the text would be very welcome. We can probably mention Christoph in the release note for Nightly/beta and maybe have him mentioned in one of our These Weeks in Firefox series on blog.nightly.mozilla.org (contact Mike Conley for that).
Comment 31•2 years ago
|
||
Release Note Request (optional, but appreciated)
[Why is this notable]: In Finder on macOS, there used to be no visual indicator to show whether or not a downloaded file had completely downloaded yet. This could result in confusion when a user would attempt to use or run the file, since it may not have finished downloading yet. This was a long-standing bug, and a volunteer unexpectedly contributed a sizeable patch to address this shortcoming.
[Affects Firefox for Android]: no
[Suggested wording]: Finder on macOS now displays download progress for files being downloaded.
[Links (documentation, blog post, etc)]: none
Comment 32•2 years ago
|
||
Christoph, thanks much for taking this bug and seeing it through to completion! Great work!!
If you'd like to work on other bugs and/ or projects in the future, please feel free to reach out!
Description
•