Closed
Bug 399632
Opened 17 years ago
Closed 17 years ago
Resume (not restart) a download after firefox crashes
Categories
(Toolkit :: Downloads API, enhancement)
Toolkit
Downloads API
Tracking
()
VERIFIED
FIXED
mozilla1.9beta1
People
(Reporter: velcrospud, Assigned: Mardak)
References
Details
Attachments
(1 file, 4 obsolete files)
2.93 KB,
patch
|
mconnor
:
approvalM9+
mconnor
:
approval1.9+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007101104 Minefield/3.0a9pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007101104 Minefield/3.0a9pre Downloads are restarting from scratch after a hard program crash - now that cross session resume works it seems it would be put to good use here. Resuming works fine because I can manually change the state in the database and get it to resume from where it left off. After a crash, the state is left as 0 (downloading). Setting it to 4 (paused) and then starting firefox allows one to resume the download from where it left off. Reproducible: Always Steps to Reproduce: I'm simulating a hard crash by ending the firefox process from the windows task manager. (I assume this is an accurate enough simulation of program or even computer wide crash as far as firefox is concerned) SQLite Database Browser is a handy tool for editing the database while firefox is closed.
Assignee | ||
Updated•17 years ago
|
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Depends on: 399817
Ever confirmed: true
Flags: blocking-firefox3?
OS: Windows XP → All
Hardware: PC → All
Assignee | ||
Comment 1•17 years ago
|
||
Let's use auto-start + resumealldownloads hammer!
Comment 2•17 years ago
|
||
Comment on attachment 284884 [details] [diff] [review] v1 >+ // Convert supposidly-active downloads into downloads that should auto-start nit: supposedly s/auto-start/auto-resume/ r=sdwilsh
Attachment #284884 -
Flags: review?(comrade693+bmo) → review+
Assignee | ||
Comment 3•17 years ago
|
||
Bind instead of checking for 1. autoStart -> autoResume.
Attachment #284884 -
Attachment is obsolete: true
Attachment #284892 -
Flags: review?(comrade693+bmo)
Assignee | ||
Comment 4•17 years ago
|
||
I /knew/ I had an auto-start somewhere else...
Attachment #284892 -
Attachment is obsolete: true
Attachment #284893 -
Flags: review?(comrade693+bmo)
Attachment #284892 -
Flags: review?(comrade693+bmo)
Assignee | ||
Comment 5•17 years ago
|
||
Ah right. Saving the file doesn't automatically update the patch........ :p
Attachment #284893 -
Attachment is obsolete: true
Attachment #284894 -
Flags: review?(comrade693+bmo)
Attachment #284893 -
Flags: review?(comrade693+bmo)
Comment 6•17 years ago
|
||
Comment on attachment 284894 [details] [diff] [review] v1.3 r=sdwilsh Can we add a comment stating that this method should be called before we try to auto resume downloads just to make it explicitly clear please?
Attachment #284894 -
Flags: review?(comrade693+bmo) → review+
Assignee | ||
Comment 7•17 years ago
|
||
(In reply to comment #6) > Can we add a comment stating that this method should be called before we try to > auto resume downloads just to make it explicitly clear please? Commented.
Attachment #284894 -
Attachment is obsolete: true
Attachment #284974 -
Flags: approval1.9?
Updated•17 years ago
|
Attachment #284974 -
Flags: approval1.9? → approval1.9+
Updated•17 years ago
|
Flags: blocking-firefox3? → blocking-firefox3+
Assignee | ||
Updated•17 years ago
|
Whiteboard: [has patch][has reviews]
Version: unspecified → Trunk
Comment 8•17 years ago
|
||
Just a reminder to please commit this by Monday if you want to get it in before beta. Otherwise, approval1.9+ will be revoked, and you will need to re-request it after M9 if you still want to land the patch. If you would like somebody else to commit this for you, please add the "checkin-needed" keyword.
Assignee | ||
Comment 9•17 years ago
|
||
This bug depends on some others.. going backwards: Bug 399817 needs approval Bug 399816 ready Bug 399815 needs approval Bug 395144 needs approval Bug 399563 needs approval
Comment 10•17 years ago
|
||
Comment on attachment 284974 [details] [diff] [review] v1.4 Resetting all approval1.9+ flags on bugs that have not been checked in by Oct 22 11:59 PM PDT. Please re-request approval if needed.
Attachment #284974 -
Flags: approval1.9+
Updated•17 years ago
|
Attachment #284974 -
Flags: approval1.9?
Updated•17 years ago
|
Attachment #284974 -
Flags: approvalM9+
Attachment #284974 -
Flags: approval1.9?
Attachment #284974 -
Flags: approval1.9+
Assignee | ||
Comment 11•17 years ago
|
||
Checking in toolkit/components/downloads/src/nsDownloadManager.cpp; /cvsroot/mozilla/toolkit/components/downloads/src/nsDownloadManager.cpp,v <-- nsDownloadManager.cpp new revision: 1.144; previous revision: 1.143 done Checking in toolkit/components/downloads/src/nsDownloadManager.h; /cvsroot/mozilla/toolkit/components/downloads/src/nsDownloadManager.h,v <-- nsDownloadManager.h new revision: 1.56; previous revision: 1.55 done
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Flags: in-testsuite?
Flags: in-litmus?
Resolution: --- → FIXED
Whiteboard: [has patch][has reviews]
Target Milestone: --- → Firefox 3 M9
Assignee | ||
Comment 12•17 years ago
|
||
Testcase would probably consist of a state=downloading file in the sqlite db then starting dlmgr and seeing if its last update time changed.
(In reply to comment #12) > Testcase would probably consist of a state=downloading file in the sqlite db > then starting dlmgr and seeing if its last update time changed. Talked to Edward via IRC, and this actually isn't compulsory. I've downloaded several file types (.iso, .wmv, .exe, .dmg) using both FTP and HTTP and force-quit their downloads very close to the end; they all correctly resumed at their previously completed value/size, and when finished, all were checked for integrity (I did file-size compares). Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a9pre) Gecko/2007103004 Minefield/3.0a9pre Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a9pre) Gecko/2007103004 Minefield/3.0a9pre and Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a9pre) Gecko/2007103004 Minefield/3.0a9pre Verified FIXED
Status: RESOLVED → VERIFIED
Assignee | ||
Comment 14•17 years ago
|
||
(In reply to comment #12) > Testcase would probably consist of a state=downloading file in the sqlite db > then starting dlmgr and seeing if its last update time changed. Ah, I was actually referring to an idea for an xpcshell testcase.
In-litmus+ https://litmus.mozilla.org/show_test.cgi?id=4992
Flags: in-litmus? → in-litmus+
Updated•16 years ago
|
Product: Firefox → Toolkit
You need to log in
before you can comment on or make changes to this bug.
Description
•