Closed
Bug 399838
Opened 17 years ago
Closed 17 years ago
Automatically init (not open) the download manager when starting the app
Categories
(Toolkit :: Downloads API, enhancement, P1)
Toolkit
Downloads API
Tracking
()
VERIFIED
FIXED
mozilla1.9beta3
People
(Reporter: Mardak, Assigned: Mardak)
References
Details
Attachments
(1 file, 1 obsolete file)
2.80 KB,
patch
|
mconnor
:
review+
|
Details | Diff | Splinter Review |
From bug 399817 comment #0: A separate bug should be filed to init the download manager when starting the app.. similar to session restore. So if we always restart dlmgr, we won't the code in session restore either. Without a fix for this bug, even with bug 399817 fixed, the auto-resume downloads will only resume /after/ the download manager is opened. How should this be done without impacting startup time too much? The dlmgr doesn't have to get inited exactly when the app starts, but after the homepage loads could be good.
Assignee | ||
Comment 1•17 years ago
|
||
I'm not sure if this is the most appropriate place to do this, but it's probably the least amount of code change possible. ;) I'm not sure how this affects Ts, etc. The download manager doesn't necessarily have to start with 0 timeout.. it could be something arbitrarily higher.
Comment 2•17 years ago
|
||
Comment on attachment 285042 [details] [diff] [review] v1 this really should not affect Ts, as it runs after the first window loads. r=me.
Attachment #285042 -
Flags: review?(dietrich) → review+
Comment 3•17 years ago
|
||
http://quotes.burntelectrons.org/2851
Assignee | ||
Updated•17 years ago
|
Attachment #285042 -
Flags: approval1.9?
Comment 4•17 years ago
|
||
(In reply to comment #3) > http://quotes.burntelectrons.org/2851 > spun off to bug 400102
Comment 5•17 years ago
|
||
Note, we do have Bug 386605.
Comment 6•17 years ago
|
||
(In reply to comment #5) > Note, we do have Bug 386605. > that doesn't affect Ts's shortcomings, only our methods of gaming it. s/delayedStartup()/new delayed startup event/.
Assignee | ||
Updated•17 years ago
|
Whiteboard: [has patch][has reviews]
Updated•17 years ago
|
Attachment #285042 -
Flags: approvalM9+
Attachment #285042 -
Flags: approval1.9?
Attachment #285042 -
Flags: approval1.9+
Assignee | ||
Comment 7•17 years ago
|
||
For a litmus test, quit firefox with a download at ~90% going then restart firefox. The download should finish without opening the download manager (the all downloads done message should pop up). Checking in browser/components/sessionstore/src/nsSessionStore.js; /cvsroot/mozilla/browser/components/sessionstore/src/nsSessionStore.js,v <-- nsSessionStore.js new revision: 1.81; previous revision: 1.80 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
Comment 8•17 years ago
|
||
Backing out due to Bug 401052. Also, this fix isn't technically correct since this will only do that for browser, but not any other toolkit app. *cough*delayed-startup*cough*
Assignee | ||
Comment 9•17 years ago
|
||
dietrich: Any suggestions now that we know the current patch affects Ts? A simple hack would just be to setTimeout with a non-0 value like.. 60000 -- if the user opens the download manager before that, the downloads will auto-resume then, if not downloads will auto-resume at the 1 minute mark. sdwilsh: If we just want this start-dlmgr-at-start feature for just firefox for now, this should be filed under something else? Would the delayed-startup-event be accessible for all toolkit users?
Comment 10•17 years ago
|
||
we already have a delayed startup for Firefox, but we really should be doing that for toolkit.
Updated•17 years ago
|
Flags: blocking-firefox3?
Target Milestone: Firefox 3 M9 → Firefox 3 M10
Updated•17 years ago
|
Attachment #285042 -
Flags: approvalM9+
Attachment #285042 -
Flags: approval1.9+
Updated•17 years ago
|
Flags: blocking-firefox3? → blocking-firefox3+
Updated•17 years ago
|
Priority: -- → P2
Updated•17 years ago
|
Whiteboard: [needs new patch]
Assignee | ||
Comment 11•17 years ago
|
||
Comment on attachment 285042 [details] [diff] [review] v1 Where's the delayed start up for Firefox? Initializing the download manager service at startup could be something for each app to choose if they want it or not. >+ aWindow.setTimeout(this.retryDownloads, 0); s/0/10000/ ?
Assignee | ||
Comment 12•17 years ago
|
||
Oh, probably meant browser/base/content/browser.js's delayedStartup ?
Comment 13•17 years ago
|
||
That's the one. As it stands, I'm okay with that as a reasonable step for apps. Not the ideal solution, but good enough for now (need to document it!)
Updated•17 years ago
|
Priority: P2 → P1
Assignee | ||
Comment 14•17 years ago
|
||
Starts the download manager after 10 seconds. Tested with an almost-complete download and quitting the app. Restarted and the growl notification showed up and ~12 seconds later the 'all downloads complete' notification showed up.
Attachment #285042 -
Attachment is obsolete: true
Attachment #293301 -
Flags: review?
Assignee | ||
Updated•17 years ago
|
Attachment #293301 -
Flags: review? → review?(mconnor)
Assignee | ||
Comment 15•17 years ago
|
||
Loading the service before the user opens the download manager window will help it show up faster. (bug 404006)
Blocks: 404006
Status: REOPENED → ASSIGNED
Whiteboard: [needs new patch]
Target Milestone: Firefox 3 M10 → Firefox 3 M11
Comment 16•17 years ago
|
||
I like this approach a lot better.
Comment 17•17 years ago
|
||
Comment on attachment 293301 [details] [diff] [review] v2 please make sure any appropriate docs around the dlmgr know that to get auto-resume, you need to init the service in this way?
Attachment #293301 -
Flags: review?(mconnor) → review+
Assignee | ||
Comment 18•17 years ago
|
||
Checking in browser/base/content/browser.js; /cvsroot/mozilla/browser/base/content/browser.js,v <-- browser.js new revision: 1.914; previous revision: 1.913 done Checking in browser/components/sessionstore/src/nsSessionStore.js; /cvsroot/mozilla/browser/components/sessionstore/src/nsSessionStore.js,v <-- nsSessionStore.js new revision: 1.88; previous revision: 1.87 done
Status: ASSIGNED → RESOLVED
Closed: 17 years ago → 17 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 19•17 years ago
|
||
sdwilsh: Where to find the docs about using download manager? Watching Ts to see if this affects it again.
Comment 20•17 years ago
|
||
What docs? If there's a page on nsIDownloadManager, I suppose that's the best place for it...
in-litmus+ https://litmus.mozilla.org/show_test.cgi?id=5021 Verified FIXED using ftp://ftp.mozilla.org/pub/diskimages/Firefox1.0PR.iso with: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b3pre) Gecko/2008011504 Minefield/3.0b3pre Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008011504 Minefield/3.0b3pre and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008011504 Minefield/3.0b3pre
Status: RESOLVED → VERIFIED
Flags: in-litmus? → in-litmus+
VM cut-and-paste-- :-( Last build ID should be Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b3pre) Gecko/2008011504 Minefield/3.0b3pre
Updated•16 years ago
|
Product: Firefox → Toolkit
You need to log in
before you can comment on or make changes to this bug.
Description
•