Closed Bug 101711 Opened 23 years ago Closed 14 years ago

Download throttling (limit download speed/bandwidth for Saving File)

Categories

(Toolkit :: Downloads API, enhancement)

Product:
Toolkit
Component:
Downloads API
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 298252

People

(Reporter: aha, Unassigned)

References

Details

When I'm actually saving file, Mozilla takes all available line's bandwith.
Sometimes is useful to download slowly (for long time) with more free bandwith
for more important work or for next workers on same line.

I think, that possibility to limit download speed for Saving File (something
like a line shaping in WANs) will be useful for a part of Mozilla users.
No dupes found. Marking NEW. 

Adam: In future, please use the Bugzilla Helper to report bugs:
http://www.mozilla.org/quality/help/bugzilla-helper.html
(among other things, it automagically adds your Build ID)

-> Networking: FTP, but that's a bit of a guess

Old summary:
"[RFE] possibility to limit download speed for Saving File"

New summary:"
"[RFE] Download throttling (limit download speed for Saving File)"
Assignee: asa → bbaetz
Status: UNCONFIRMED → NEW
Component: Browser-General → Networking: FTP
Ever confirmed: true
QA Contact: doronr → benc
Summary: [RFE] possibility to limit download speed for Saving File → [RFE] Download throttling (limit download speed for Saving File)
Only for FTP downloading? In these days are very often a large files provided
via HTTP, so I think that both (or all) transfer protocols could be supported.

[For Rembrandt: Are you sure, that Build ID (Gecko/2001092403) is relevant in
this case? I'm using Bugzilla Helper sometimes for reporting bugs, but IMHO this
RFE don't require it.]
You'd have to do this by having the front end suspend/resume the download so
that the tcp throttling kicks in. Yuck.

I think that only http supports those APIs ATM, anyway.

darin - this would be an xpapps bug once your fix to not read everything from
ODA goes in, right?
Adam: I just picked Networking:FTP as a starting point. But, as you wish:

-> Networking

As for the Build ID: That can be important, even for RFEs, in case the feature
cited has been implemented in a build more recent than the reporter's.
Assignee: bbaetz → neeti
Component: Networking: FTP → Networking
Bradley -> CC.

Bradley: I've added you to the CC list because, when I changed the Component
over to Networking (at the request of Adam), you're no longer listed as QA
Contact. But, feel free to remove yourself from the CC list if this bug no
longer interests you.
Nah, this one is actually xpapps once bug 93055 is fixed - just limit how much
you read.
Assignee: neeti → pchen
Component: Networking → XP Apps
Depends on: 93055
QA Contact: benc → sairuh
You mean assignee :) This is fine, thanks.
It's not exactly the TCP way... if your server is fast, too bad for everyone
else in the collison domain...

spam: over to File Handling. i have not changed the assigned developer [or the
other fields for that matter], so if anyone realizes that a bug should have a
more appropriate owner, go ahead and change it. :)
Component: XP Apps → File Handling
->law/future
Assignee: pchen → law
Target Milestone: --- → Future
actually i see something else: my mozilla downloads never exceed about 64kB/s. 
I downloaded several nightly builds of Mozilla, using Internet Explorer 6 and
Mozilla, either at the same time or shortly after one another. I tried on a
Windows NT4 and a Windows XP (Pro) machine, and every time, Mozilla downloads
never exceeds 64kB/s whereas Explorer goes to about 250kB/s.
patrick: you should file a separate bug for that problem... sounds like you're
seeing something very serious!
What about moving this bug to Download Manager?
anyone actually working on this? Seems like a GREAT feature to have! (sorry not
trying to push you, Bill)
QA Contact: sairuh → petersen
.
Assignee: law → blaker
Component: File Handling → Download Manager
Summary: [RFE] Download throttling (limit download speed for Saving File) → Download throttling (limit download speed for Saving File)
*** Bug 187632 has been marked as a duplicate of this bug. ***
*** Bug 190310 has been marked as a duplicate of this bug. ***
Summary: Download throttling (limit download speed for Saving File) → Download throttling (limit download speed/bandwidth for Saving File)
*** Bug 200707 has been marked as a duplicate of this bug. ***
*** Bug 218910 has been marked as a duplicate of this bug. ***
*** Bug 244114 has been marked as a duplicate of this bug. ***
*** Bug 251879 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
Just a tiny note, I use Download Accelerator on win32 for larger files. In their
latest version they added buttons to set "low" "co-operative" and "full"
bandwidth. It is indeed very handy! You can set to co-operative and keep
browsing, getting email etc happily.
For the record, these seem to correspond to about 25%, 60%, and 100% of
available bandwidth.
It would be nice to see this in Mozilla; however, a download manager with resume
would be more important.
Perhaps on Windows this could be implemented using the BITS (background intelligent transfer service) which is designed for this purpose and used by windows update.
Assignee: bross2 → download-manager
QA Contact: chrispetersen
Target Milestone: Future → ---
I'd really like to see this feature.

When downloading files, please allow control of download rate. For example, if I'm
downloading a new version of Thunderbird and don't want to hog my bandwidth,
I'd like to be able to set a download speed so it takes up no more than a
specified amount of KB/s.

So, I would be able to start download the file or program, open the download
window, and see an option to limit download speed to say, 30 KB/s, letting it
download reasonably quickly while still leaving enough bandwidth for me to surf
the web without delays.

There can also be separate preferences to set hours where different rates can
be used.

The BitTorrent client "Transmission" for Linux and Mac has bandwidth limitation
settings similar to what I am requesting.

Can we see it any time soon???
It's really part of the open question "how smart should the built in downloader be". Should it be a simple, bare bones downloader, or should it have all the features of the download programs? (Pause/resume, across sessions, queuing, throttling etc). There are arguments both ways; not everyone needs a fancy one so it could be a plugin or external app; but also, downloading is a very important feature of browsers so arguably should be a high quality implementation.

Is there a meta bug about this, or a discussion somewhere?
OK, I see download throttling is listed in the Wiki
http://wiki.mozilla.org/Firefox:Download_Manager
Wait a minute. Download speed limitation is listed there as a FF 3 feature. So where is it?
(In reply to comment #26)
> OK, I see download throttling is listed in the Wiki
> http://wiki.mozilla.org/Firefox:Download_Manager

That's immensely out of date and does not reflect Firefox's current implementation of the Download Manager. You're welcome to ignore it.
Shall I delete the content of that wiki page then, because it is just deceptive.

Or is the wiki totally pointless and to be generally ignored? If so why is it on the mozilla site?

By the way, how do I set this bug to apply to suite AND firefox?
Any updates? This should at least make Firefox 3.1. It wouldn't require the download manager to be over-complicated, either. There can just be a small button or icon in the download window (and maybe also in the general Firefox Preferences window) which pops up a bandwidth controller -- this would be an extremely useful feature, not to mention it would also help draw people away from IE.
You know what, I'm thinking now that it'd make more sense to extend this feature and take it away from the download manager. It should be a separate tab in the Preferences window that gives full control of bandwidth for not just the download manager (with its time restraints and all), but also for Firefox itself as a program or limiting bandwidth per tab/window. That could help, say, if you are loading lots of tabs and one (like a video) is preventing the others from having sufficient bandwidth to load.
The SeaMonkey team has no intention to work on this, if you're still interested in it, please take this to toolkit's download component for getting the backend done.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
Assignee: download → nobody
Status: RESOLVED → REOPENED
Component: Download & File Handling → Download Manager
Product: SeaMonkey → Toolkit
QA Contact: download.manager
Resolution: WONTFIX → ---
Status: REOPENED → RESOLVED
Closed: 15 years ago → 14 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.