Closed Bug 236755 (BitTorrent) Opened 20 years ago Closed 9 years ago

Support BitTorrent as a file download mechanism

Categories

(Core Graveyard :: File Handling, enhancement)

Product:
Core Graveyard
Component:
File Handling
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: gerv, Unassigned)

References

Details

(Keywords: helpwanted, Whiteboard: [p-opera] See comment 11) 

Note: this is _not_ a duplicate of bug 203571.

There is strategic value to mozilla.org in building in support for the
BitTorrent protocol to Firefox and Mozilla, so that a user can click on links to
.torrent files and have the file downloaded seamlessly in the Download Manager.

1) We could set up trackers for new Firefox/Mozilla versions, and it would ease
the load on our download servers.

2) Content providers love BitTorrent because it saves them bandwidth. If we
support it natively, our users will get a much better download experience than
IE users hitting overloaded servers via HTTP for the latest hot download.

This view is held by a lot of people - see the dupes of bug 203571.

Unfortunately, a slightly over-excited initial comment and a rather confused
discussion in that bug led to it being WONTFIXED, and any bug which mentions
BitTorrent has been duped against it ever since, even if it has different ideas.

My suggestions is roughly what Henry James, BitTorrent developer, is thinking of
in bug 203571, comment 13, paragraph 5. Mozilla should handle files of type
application/x-bittorrent internally, just like application/octet-stream - except
that it would download the tracker file, and then download the referenced file
using the BitTorrent protocol instead of HTTP.
Q and A:

* Why is it bad to pass this off to a helper app again? 

All the current bittorrent clients have terrible UI, and require an extra
install. It would be great if a user could click a .torrent link and have the
file downloaded to disk using the Download Manager, just as any other file.

* Why is it a problem to do this task with a plugin?

Plugins are for rendering web content in the browser.

* What about a download manager plugin, then?

This is roughly what's being suggested. It might start as an external add-in
(assuming that's technically possible), but the big value comes from being
integrated by default.

* What about <img src="blah.jpg.torrent"> ?

The BitTorrent protocol isn't suited for that sort of thing. For a start, it's
slow to get moving, and has a co-ordination overhead.

* What about a torrent:// URL scheme?

There's no such protocol. And if there was, other browsers wouldn't understand
it. And it would require all the info in the .torrent file to be encoded in the
URL - that could make the URL longer than is permitted.

* How would you handle the UI?

Ideally, downloading a file over BitTorrent would be as simple as downloading it
over HTTP. Therefore, we would need to make quite a few choices for the user
that other BitTorrent clients expose.

My idea is as follows:

- Download appears in download manager just like any other, with progress bar
from 0 to 100%.
- The user has no idea which pieces have been got and which haven't.
- There is no way to prioritise one torrent over another.
- Use various tricks to guess at user's u/l and d/l bandwidth, and set
parameters related to that.
- Uploading continues until either:
  - The user exits the browser
  - The user has sent 150% (hidden pref) of the amount of data received.

There are error conditions specific to .torrents we would need to work out UI for:

- No source of a particular piece
  - This can be determined up front; how do we tell the user?
- User is behind a firewall and so their download will suck
  - It's a shame .torrent files don't contain an "alternate URL", with no
    quality of service guarantees attached to it.

* Is there code we can use?

http://libtorrent.sourceforge.net is under the MIT license. It may well be a
good start.

Gerv

> It might start as an external add-in (assuming that's technically possible),

It should be.  If it's not, file api bugs as necessary until it is.  In fact, I
think we could make it possible to do this with a helper app (with a DDE/xremote
api for the helper to talk to the download manager).

But frankly, that's work and this should be pretty "easily" (in terms of
integration into Mozilla code) doable using a stream converter that will convert
the bittorrent type to whatever the real type is (by actually doing the load).

> * What about <img src="blah.jpg.torrent"> ?
> 
> The BitTorrent protocol isn't suited for that sort of thing. For a start, it's
> slow to get moving, and has a co-ordination overhead.

Nice way to evade the question.  How about answering it?  What exactly should
the tag above do?

A much more interesting question is whether there should be a difference between
just clicking on the torrent link and doing "save link as" on the torrent link.
 The stream converter scenario would not address the latter, of course.
*** Bug 203571 has been marked as a duplicate of this bug. ***
Implementing this nativly certainly would be an excellent feature, and a massive
advantage for users over IE / other competitors. My one question is how would
you deal with the situation of sharing post download? The network depends on
people "leaving the window open" afterwards; what would be the feasability / the
likelihood for this to happen with a browser?
Implementing this nativly certainly would be an excellent feature, and a massive
advantage for users over IE / other competitors. My one question is how would
you deal with the situation of sharing post download? The network depends on
people "leaving the window open" afterwards; what would be the feasability / the
likelihood for this to happen with a browser?
(In reply to comment #2)

> > * What about <img src="blah.jpg.torrent"> ?
> > 
> > The BitTorrent protocol isn't suited for that sort of thing. For a start, it's
> > slow to get moving, and has a co-ordination overhead.
> 
> Nice way to evade the question.  How about answering it?  What exactly should
> the tag above do?
> 
> A much more interesting question is whether there should be a difference between
> just clicking on the torrent link and doing "save link as" on the torrent link.

I'm not sure he was dodging the question; essentially he is asking whether one
could put an image say on a bittorrent net, and then link to it via <img src=""
/> tag. Clearly, doing this would save bandwidth. However, this is unfeasable
due to the time needed to contact a tracker, and then initialise individual
connections with peers. For a webpage to render in a reasonable time doing this
would be impossible.
> how would you deal with the situation of sharing post download?

I addressed that vaguely in my Q&A. My idea was that we'd measure bandwidth and
use, say, 75% of it. We'd keep uploading until we'd uploaded, say, 150% of the
file size, then stop. If the browser was closed, obviously we'd stop then too. 

We might start uploading again if the browser restarted, the tracker was still
there and the file hadn't moved - but that sounds complex. Let's see how far the
above approach takes us.

> What exactly should the tag above do?

Whatever falls out of the design. ;-) In other words, it could do anything.

> A much more interesting question is whether there should be a difference 
> between just clicking on the torrent link and doing "save link as" on the 
> torrent link.

That is an interesting question. Ideally, of course, this would work too. 

Gerv
> Ideally, of course, this would work too.

Then how do you save the torrent file?

Note that this is NOT how it works for various other "spawn off random stuff"
files like mp3 playlists and so forth.  If we want it to work like you propose,
I would say that it _should_ be a protocol handler (because otherwise someone
embedding gecko who didn't perform major surgery on their embedding app to let
it know about torrent would have torrent working when clicking on links but not
when doing save link as).
I really don't feel comfortable with the idea that application/x-bittorrent
files should react in a magical way.

If we did this, the same result should happen whether you right-clicked on a
link and saved it, clicked on the link and viewed it, or referred to it via an
<img>, <object>, or background:url() syntax. This would leave no way to get at
the real end of the link, which would arguably make us non-HTTP compliant, IMHO.
It also seems fundamentally wrong to me. (It tickles my quality assurance "here
be bugs" sense.)

Couldn't we implement moz-torrent: (or some other scheme in coordination with
Bram Cohen) and simply have application/x-bittorrent offer to download the file
"using the BitTorrent protocol"? (Just like looking at an application/
octet-steam file should offer to "open the file in Mozilla" if it is really a
text/html or image/png image.)

Hmm. I need to think more about this.
Ian;

I can see your point; why bit torrent? Well, Bit torrent is different in that it
really is a big technology that is becoming more and more widely used. If
integrated it would be a major selling point for mozilla; able to download
torrents as standard. 

I think however it needs to be clear as to what specifically one would try and
do here. The idea of integrating a bittorrent client into mozilla is A) Cool and
B) useful to the extreme. Coming up with other ideas (<img scr="bittorrent">) is
nice, but shouldn't detract from the original and very unique idea.
application/x-bittorrent support could be an nsIURIContentListener; to show the
info in the dl manager, it could create an nsIDownload object and call its
nsIWebProgressListener methods normally. This is doable as an extension.

This would mean that this would be invoked when the file would otherwise be
shown by mozilla (left-click on the file), but not when saving the .torrent file
to disk (right-click, save target as).

Wow. This is a way for which these APIs work extremely well. I'm surprised, I
didn't think such a way existed.

whoa, how could this bug get 9 comments within an hour or so?
> Couldn't we implement moz-torrent:

We would need that anyway, actually, since we would need a way of making network
connections to get the data, and the way to do that in mozilla is to have a
protocol and a protocol handler. 

Biesi, of the 12 comments (counting comment 0) three are pointless advocacy and
one is dup-noise... of the remainder, approximately 4 have information that's
useful for implementing this.  The rest are attempts to figure out what people
are talking about.  ;)
Hmm, yeah.  Using an nsIURIContentListener may work better than a streamlistener
in that it would prevent HTML content served up as a torrent from being rendered
inline.
> I can see your point; why bit torrent?

That wasn't my point at all, please re-read my comment.


> Hmm, yeah.  Using an nsIURIContentListener may work better than a 
> streamlistener in that it would prevent HTML content served up as a torrent 
> from being rendered inline.

So an http://.../foo.torrent file would be downloaded, but a
moz-torrent:http://.../foo.torrent file would be rendered inline, right? That
seems to me to be what we want if we do this.
Regarding right clicking and saving torrents.  I think it should save the
torrent, and associate it with mozilla, just like a you can save a bookmark to
the desktop.  And launching it initiates the download.

(In reply to comment #9)
> I really don't feel comfortable with the idea that application/x-bittorrent
> files should react in a magical way.
> 
> If we did this, the same result should happen whether you right-clicked on a
> link and saved it, clicked on the link and viewed it, or referred to it via an
> <img>, <object>, or background:url() syntax. This would leave no way to get at
> the real end of the link, which would arguably make us non-HTTP compliant, IMHO.
> It also seems fundamentally wrong to me. (It tickles my quality assurance "here
> be bugs" sense.)

I don't see how this is really any different than a SMIL file, or a .ram, or
.asx, .qt, etc.  All of the above point to streams that don't use the HTTP
protocol (IIRC they all use RTSP).  

The proposal, is just to do this internally, by beefing up the Download Manager
itself.  Rather than launch another Application.

I think we should lobby for a torrent:// protocol.  It's a good idea, and when
BitTorrent matures into a 2.0 protocol, may be wise.  

Regarding the use in embedding, such as image tags... I don't see the point. 
For most cases, torrents take a few seconds to transfer any data.  The page
would most likely timeout anyway. 

> 
> Couldn't we implement moz-torrent: (or some other scheme in coordination with
> Bram Cohen) and simply have application/x-bittorrent offer to download the file
> "using the BitTorrent protocol"? (Just like looking at an application/
> octet-steam file should offer to "open the file in Mozilla" if it is really a
> text/html or image/png image.)
> 
> Hmm. I need to think more about this.


I kicked off this round of BitTorrent debates a few days ago with this:
http://robert.accettura.com/archives/000323.shtml

There are a few questions I recieved, that I will address on my blog regarding
my idea, and reasoning.. perhaps later tonight or early this week.

I think Gerv covered most of it with his rather lengthy opening comments on the bug.


Bottom line:  I think it should be treated only through the download manager. 
Just download per the bittorrent protocol.  A useful feature for the end user.

As Gerv states, content providers LOVE bittorrent.  We will be seeing more, not
less of it.  Mozilla has a silent history of being inovative, and *better*.  I
think it's great to lead the way once again, and provide users with a feature
they can really use.
> So an http://.../foo.torrent file would be downloaded

Yes, if you click on that link.

> but a moz-torrent:http://.../foo.torrent file would be rendered inline, right?

The moz-torrent protocol scheme wouldn't work quite like that.  It would simply
be a way of taking the information in the .torrent file and encoding it in a
URI.  The protocol handler implementation would then take the information in the
URI and use it to get the actual data.  Just a way of passing data from the
application to the network layer.

But yes, if you concocted a moz-torrent uri of the sort that we would construct
from a .torrent file then you could get the content to render inline.
Note that Robert seems to be agreeing with me and Ian and disagreeing with
Gerv... on the right-click issue (though he also seems to think that he's
disagreeing with Ian).

Anyway, as biesi and I said this is trivial to hook into Mozilla as an extension
-- this is one area where our embedding APIs actually work and all.
(In reply to comment #14)
> So an http://.../foo.torrent file would be downloaded,

Not in the "save link target as" case, though (it would save the .torrent
description file), and <img src> would also not work.

> but a
> moz-torrent:http://.../foo.torrent file would be rendered inline, right? That
> seems to me to be what we want if we do this.

If you want to add a moz-torrent: url scheme, sure... I disagree with comment 12
in this respect, you can ignore protocol schemes just fine...
(In reply to comment #17)
> Note that Robert seems to be agreeing with me and Ian and disagreeing with
> Gerv... on the right-click issue (though he also seems to think that he's
> disagreeing with Ian).

No, I don't think I'm agreeing or disagreeing with anyone.  I have my own
opinion ;-)

I just think a certain way about that issue.  Not meaning to create sides in the
debate.  Guess I wrote that in the wrong location of that comment.
> The moz-torrent protocol scheme wouldn't work quite like that.  It would simply
> be a way of taking the information in the .torrent file and encoding it in a
> URI.

Problem is, .torrent files can often contain a lot of data. Isn't there a length
limit on URIs? Or would it not be a problem because it would only be internal?

Re: right-click, Ian's reasoning seems sound. Right-click should save the
.torrent file (and we should take the association so double-clicking it starts
the download). People are used to dealing with this with .m3u, so I guess they
can cope with it in this case.

Gerv

(In reply to comment #16)
> Just a way of passing data from the
> application to the network layer.

The network layer needs not be involved here... I mean, in the end, this is all
just internal to the extension that implements all this; what does a protocol
handler gain you?

(well, if you decide you want one so that it can be used, things are different
of course (as opposed to "have to implement one to support bittorrent"))
> what does a protocol handler gain you?

Hmm... I guess you could write an nsIChannel impl (since download manager _will_
need that) and just give it the http:// (or whatever) URI and not have a
protocol handler at all...

So ignore what I said.  Comment 11 is what should be done.
Keywords: helpwanted
Whiteboard: See comment 11
(In reply to comment #20)
> Re: right-click, Ian's reasoning seems sound. Right-click should save the
> .torrent file (and we should take the association so double-clicking it starts
> the download). People are used to dealing with this with .m3u, so I guess they
> can cope with it in this case.
> 

A third path could be prompting the user that it's a BitTorrent download, and
ask if it should "save the torrent so you can download later", or actually
retrieve the download.

That might by considered UI bloat, but I just thought I would throw that out as
an idea.  Not every user may be aware exactly what a .torrent is.
Robert: that doesn't really make BitTorrent downloads as easy to use as HTTP/FTP
downloads :-) I think we can assume that anything served as
application/x-torrent, just as anything served as application/octet-stream, is
for saving to disk. This narrowing of focus avoids a load of UI issues.

Gerv

Looks like BitTorrent is getting momentum, check this story on Slashdot:
BitTorrent Gains Corporate Support --
http://slashdot.org/article.pl?sid=04/03/17/0210237&mode=nested&tid=126&tid=187&tid=95

It seems that among companies required to distribute large quantities of data to
their customers BitTorrent is becoming very popular.
Most users will see the 'upload 150%' feature as a bug, because their internet
connection becomes less responsive after a couple of downloads, and they will
'fix' it by restarting the browser. For an end-user, it's the same as a memory
leak that forces you to restart the app from time to time.
Most users will see the 'upload 150%' feature as a bug, because their internet
connection becomes less responsive after a couple of downloads,

Why so? The load is on the outgoing, not the incoming side, which is hardly used
- and I'd hope we could find a way to give priority to non-Bittorrent outgoing
traffic.

Gerv
(In reply to comment #27)
> Why so? The load is on the outgoing, not the incoming side, which is hardly used

in case that's uploading near the limit of the connection, that really does kill
download performance as well (and increases latency a lot)
As Gerv said, it would be ideal be able to throttle (most likely by percentage
like most P2P products).

Upload does increase latency.  But of course that varies based on the connection
as well.

BitTorrent stinks for dialup users.  But broadband users love it.  If your on a
network at school or work, you love it even more (since many home broadband
providers have caps).

Then again... on a cable modem with a 3.5Mbps cap.  Several downloads at the
same time severely effect my performance.... so should we prohibit multiple
downloads?  Of course not.  Let the user decide what they want to do.

As said earlier, BitTorrent has stratigic advantage.  If certain users don't use
it.  That's fine.  I'm sure there are users who will never use tabs either.  But
that doesn't defeat their worth.  Many find them to be a great addition.

I know at school, I can use bittorrent with no real degration of performance.
I would love to see native bit torrent support within firefox.

Sure users might not understand that leaving the download open after helps
people download the file but, but that's what writing documentation is all about.
Seems like a good reason to support it. =)

http://in.tech.yahoo.com/041103/137/2ho4i.html

According to British Web analysis firm CacheLogic, BitTorrent accounts for an
astounding 35 percent of all the traffic on the Internet -- more than all other
peer-to-peer programs combined -- and dwarfs mainstream traffic like Web pages.
The last post I saw on this was a month ago. Is there a consensus that this sort
of a thing would be a good core feature for FF? If so, is someone already
working on it, or is it in need of developers?

As for my 2 cents, I would like to see this implemented, though I think that
some of the behaviors specified herein should be made as options (such as
whether to expose what pieces have been retrieved). Also of import would be the
ability to restore a partially downloaded torrent.
Indeed BT would rock as a core transfer protocol under Firefox.

I even created a mockup to how a BT transfer could look in the download box.

http://members.westnet.com.au/talez/firefoxbt.png

How I imagine it:

* User clicks on a link and it acts like a HTTP download
* Firefox tells the user how fast its coming down and going back up as well now
* Bittorrent *ONLY* uploads while a user is downloading
* There is a new link for BT downloads called "Support" which will keep seeding
the download until it has uploaded 100% of the download
* There should be new options in the prefs panel for auto-support, rate limiting
the uploads and possibly turning off uploading altogether
* As you can see it would for all intents and purposes look like a HTTP download
with a few minor differences

I think this would be the easiest and simplest way to implement in terms of user
participation and UI bloat. There is one extra data field and one extra link for
an extreme improvement in functionality.

I really think its something to aim for in 1.1
Unless someone steps up to take this bug soon, this is most likely a future bug,
than a 1.1.  Simply because some serious testing will be needed.
* There should be new options in the prefs panel for auto-support, rate limiting
the uploads and possibly turning off uploading altogether

Turning off uploading would be leeching and would defeat the point of having
bittorrent. I advice against a feature that would allow for turning uploading off.
(In reply to comment #36)
> * There should be new options in the prefs panel for auto-support, rate limiting
> the uploads and possibly turning off uploading altogether
> 
> Turning off uploading would be leeching and would defeat the point of having
> bittorrent. I advice against a feature that would allow for turning uploading off.

With the rise of bt being used for legitimate downloading, it might not be as
taboo as it once was.

Who cares about Joe Blogs and his 16K/sec of upload when fileplanet has 400
megabits behind a torrent.

The whole point of bittorrent is the upload, if we allow that to be disabled we
might as well not support it, since it just becomes the same as HTTP at that
point. However, I do think we should default to limiting upload to some 3kb/s or
some such, so as to not ever hit anyone's ADSL upload limit (and thus throttling
their download).
Hi everyone!

I think that if Mozilla is going to support this in the download, it should also
 eventually support downloads transparently as a file handler as well. Why not
share those caches we all have on our hard disk that were originally received as
a public url?

For example:

<img src="bt://public.server.com/url/to/image.torrent" />

If this grows in popularity, I could see this affecting the usefulness of
services such as Akamai. Do torrents have mimetype information inside of them so
that the browser would know to render that torrent as a jpeg?? =)

jon

Hmm... making bittorrent easy for all users is a challenge.  You still have to
help the user figure out how to open the necessary ports on their router :-/
(In reply to comment #40)
> Hmm... making bittorrent easy for all users is a challenge.  You still have to
> help the user figure out how to open the necessary ports on their router :-/

The solution for that is to wait about 2-4 minutes.  If upload is non-existant,
then prompt the user that they may need to open up a port in their firewall, and
redirect them to a Mozilla Help page modeled after:
http://userpages.umbc.edu/~hamilton/btclientconfig.html

which should contain a notice that they may need to "contact their network
administrator".  that's the best we could do.  

Regarding upload... we should offer the ability to throttle, but not turn off,
as the FAQ states, you are tit-for-tat with peers.
There is always the potential concept of 'fallback uri's'....

<img src="bt://uri/ , http://uri/" />

jon


As mentioned before, <img src="??(bittorrent link)??"/> are not possible/useful.
First, "fallback" is not a standard HTML feature (correct me if I'm wrong), so
that page would not work in any browser. Breaking compatibility is the opposite
of what Open Source tries to do.

Second, BitTorrent takes some time to initialize download (overhead). We would
gain nothing but slow down the page loading process. In would be useful only
for, let's say, >a few MBs, images. Those are usually linked to, not embeeded on
page, as they contain data not everyone is interested in (let's say some
scientific data or photographs); there's still no problem to offer an image over
BT, it's just an ordinary binary file in this case.
> If upload is non-existant, then prompt the user that they may need to open up
a > port in their firewall, and redirect them to a Mozilla Help page modeled after..

good luck explaining that to a typical user.  the "firewall problem" means that
it will be very difficult for this to ever be more than a fringe feature,
enjoyed by a relative minority of our userbase.  an extension would be more
appropriate imo.
Darin: are there not now firewalls where you can request it to open a port for
you? Some new feature in Windows XP, I believe. I forget the name.

If that becomes widespread, the problem might be mitigated.

But I agree, an extension is probably the best place for this code to start off.
Who knows what would happen after that?

Gerv
(In reply to comment #45)
> Darin: are there not now firewalls where you can request it to open a port for
> you? Some new feature in Windows XP, I believe. I forget the name.
> 
I think your referring to UPnP.
Will everyone stop overcomplicating things?

Why the hell are we putting torrent links inside IMG tags?

To integrate this successfully you need to do two things:
1) Maintain the status quo
2) Make it better

(1) Just treat it like it always has been with .torrent files on webpages. (2)
If you click on a link Firefox loads up the torrent internally and downloads it
as if it was another bittorrent client.

(1) No port forwarding info. It'll just confuse people. And ISPs are going to
cop the brunt of the **** from stupid idiot users. (2) Put uPnP support if you
want. As more people get uPnP capable equipment the number of zero config
uploaders will increase.

(1) For the 99% of legitimate downloads out there, people not uploading won't
mean ****. Sure it'll be nice but it won't be so mission critical to have
uploading like if you were trying to distribute an anime sub or the like. It's
not like people downloading over HTTP contribute anything already.

(2) With the integration we'll have a nice distributed, multihomed file transfer
method integrated into one of the most popular up and coming browsers.

There. I've said my piece. You can all go back to bitching about non-uploads and
trying to put bloody torrents inside <IMG> tags now.
A few short points on the topic:

1) UPnP is not a feature, but a security hole. I don't know that I believe that
Firefox should be in the position of reconfiguring people's networks,
transparently or not. If BT is blocked, then the user is going to be kinda hosed.

2) One of the largest points of the BT protocol is to decentralize the load on a
server. By offering the option to disable uploading, one of the most fundamental
assumptions of the protocol is no longer valid. Many clients will deny bandwidth
to those who throttle uploads, thus causing many potential problems for Firefox
BT users.

3) Though a BT would not be of any use to inside an IMG tag, it might be of
great use inside an EMBED tag (for Flash, QT or Java). Thus, the issue of how to
implement a BT link inside of a predefined HTML tag is non-trivial.

4) Firefox need not implement a pure BT client, but could also implement a
client for XML serialized torrents, such as those generated by Azerus. These XML
torrents could then be embedded into the page, or linked by virtue of a <link
type="torrent" rel="http://path.to/torrent/" /> entity.

Now that I've ranted my two cents worth, let me offer a few implementation
suggestions for the HTML side of things. By using XML namespaces, we can
identify BT related information as being seperate from standard XHTML 1.0 tags.
For instance, an <a /> or <embed /> entity could have a new attribute bt:btref
which links to a standard or XML torrent (determined from MIME type) which can
be used to download the content. In that way, the standard href or src
attributes act as a fallback URL. Browsers which don't understand BT could
safely ignore the bt:* attributes. As an example, consider the behavior of the
following hypothetical tag:

<a href="http://example.com/largefile.swf"
bt:btref="http://example.com/largefile.swf.torrent">test</a>

Upon clicking the link, Firefox should (depending on user preferences):
1) Automatically begin downloading largefile.swf using HTTP.
2) Automatically begin downloading largefile.swf using BT.
3) Ask the user how to download the file.

Thus, the user is still in control of downloading, we have not confused a
torrent file with what it points to (since <a
href="http://example.com/largefile.swf.torrent" /> would not invoke Firefox's BT
client unless explicitly passed), and we have not overly confused non-BT aware
browsers. Furthermore, no web standards would have been harmed in the process.
One quick note about the uploading issue: I belive that we must support some
kind of limited-bandwidth upload, it just wouldn't be right otherwise. However,
files should only be "uploadable" when the following is true:

1. The files are still available in the original downloads folder.
-and-
2. The files are listed in the Downloads window.

This would make it easy for users to monitor the files that are being uploaded,
and won't require any major changes in the UI.

Prog.
1.  we are not making up/creating a BitTorrent protocol, we are implementing the
existing protocol.  

2.  we are not modifying/creating HTML specs, we are using already existing specs.
Agree with comment #50. Mozilla should just start down/uploading the file when
it receives a file with MIME type of "application/x-torrent". Torrent file can
be used in HTTP(S) and FTP protocol. It should not be used in elements like
<img>, <embed>, and <iframe>.

And in case of <object>, I don't like the browser should render the file inline
as well.
Why must you people needlessly complicate what should be a simple process?(In
reply to comment #51)
> Agree with comment #50. Mozilla should just start down/uploading the file when
> it receives a file with MIME type of "application/x-torrent". Torrent file can
> be used in HTTP(S) and FTP protocol. It should not be used in elements like
> <img>, <embed>, and <iframe>.
> 
> And in case of <object>, I don't like the browser should render the file inline
> as well.

Exactly. Could all the people who must insist on creating a whole new way of
download torrents that would be needlessly oomplicated please create their own
bug to have a "new standard" circlejerk in.

Thank you.
It would break the web to use torrents in html itself.

Torrents take a while to find other hosts to download from.  They are not
reliable (require many people downloading at the sime time to be reliable).

They aren't a way to host the web.

They aren't in the specs.

I think that's enough conversation on the topic.  If anything, such talk should
be directed to the w3c, not Mozilla.


**Please refrain from more comments on modifying specifications.  This bug is
for someone who wants to implement the protocol in firefox.**
(In reply to comment #53)
> It would break the web to use torrents in html itself.
> 
> Torrents take a while to find other hosts to download from.  They are not
> reliable (require many people downloading at the sime time to be reliable).
> 
> They aren't a way to host the web.
> 
> They aren't in the specs.
> 
> I think that's enough conversation on the topic.  If anything, such talk should
> be directed to the w3c, not Mozilla.
> 
> 
> **Please refrain from more comments on modifying specifications.  This bug is
> for someone who wants to implement the protocol in firefox.**

Exactly. Let's just turn it into HTTP/FTP replacement its just begging to be
already.

The core reason this is so good and so "just begging to happen" is that big
sites can get together to distribute bandwidth between them. Users uploading
back to the network would just be icing on the cake.
And when I say the HTTP/FTP replacement I mean for downloading large files, not
serving the whole freaking web :D
I'm sorry I wasn't more clear. No need to start flaming.

What I was suggesting was a discussion to think about all of the things that
people might bring up if we implement this protocol within Mozilla.

I think it is very important to at least think ahead and not just focus on
providing minimal implementation of BT for just downloading files.

In case one hasn't noticed, it is entirely possible to do <img src="ftp://" />.
I'm not talking about replacing HTTP/FTP, I'm talking about adding an option to
HTTP/FTP. Why not HTTP/FTP/BT? Even in the specs, the src="" attribute is a URI,
not a URL which makes me want to believe that the Founding Fathers wanted to
make sure that 'The Web' lives longer than just HTTP/FTP does.

I also agree that if we are going to talk at the 0 foot implementation level,
the idea that using namespaces would most likely be the right way to go because
as we all know, backwards compatibility is the right way to go.

BT is useful for downloading data. As it progresses as a protocol through better
client implementations, it will get even more useful for doing so. Newer
features of clients (Azureus has this) like asking for pieces of the data with
its starting sequence makes it possible to allow previews of data and display of
images more quickly. Sure, BT might be slower than HTTP/FTP at first, but lets
think down the road a bit. The imense popularity of BT will encourage people to
improve upon it (just like Mozilla has gained in popularity/features as well...).

Clearly others are thinking about these problems... swarmstreaming has sequenced
pieces as well for previewing ability...
http://onionnetworks.com/technology/swarming/

I agree, uploading should not be disabled...but as soon as people have all this
data sitting in their downloads folder (and they happen to have the right ports
open), why the heck should we not make that information anonymously available to
others? 

Lastly, no, I don't think any of this needs to be in the first release of
Mozilla's BT client implementation. But, let's keep an open mind towards
versions 2,3,4,5,6 as well and keep our attitudes positive about this exciting
turn of events and not flame driven.

thanks,

jon
Please don't use bugzilla as a discussion forum. 

If you want something more than the subject of this bug, which is "Support
BitTorrent as a file download mechanism", for example "Support BitTorrent in
[IMG|EMBED|OBJECT|whatever] tags" or "Extend BitTorrent to create a new
protocol", open another bug saying exactly that. 

Make it dependent of this one if you want (it should be done before anyway), and
let people who want/are able to implement it do their job here. Thanks.
> My suggestions is roughly what Henry James, BitTorrent developer, is thinking
> of in bug 203571, comment 13, paragraph 5. Mozilla should handle files of type
> application/x-bittorrent internally, just like application/octet-stream -
> except that it would download the tracker file, and then download the
> referenced file using the BitTorrent protocol instead of HTTP.

Excuse me? Which part of my comment is "rougly" what you're suggesting now? 
Especially in the paragraph 5 you refer to, I made clear there are fundamental 
problems for Mozilla to "silently" handle BitTorrent downloads.

So, for the protocol, I am absolutely *against* your suggestion of Mozilla 
handling the BitTorrent protocol internally. Actually I cannot even believe 
anybody would come to any different conclusion after reading my said comment.
And again for the protocol, I suggest WONTFIX for this "bug".
Alias: BitTorrent
(In reply to comment #58)
> So, for the protocol, I am absolutely *against* your suggestion of Mozilla 
> handling the BitTorrent protocol internally. Actually I cannot even believe 
> anybody would come to any different conclusion after reading my said comment.

After reading both comments, it seems to me like you're both asking for the same
thing but with different phrasing. Perhaps it is Gerv's use of the word
"internal" that is causing confusion, but my understanding is that he is
suggesting that the current download manager handle torrents, just as you
suggested having a "sidebar" in the referenced paragraph.
Yes. I am suggesting that the Download manager handle torrents, and that the
browser make it appear to the user as no more complicated than FTPing the file.
The browser would handle all the details, and would feed back into the network
as long as it continues running, dynamically managing bandwidth to make sure the
user's use of their net connection was not impaired by the uploading. (This
doesn't have to be complicated - measuring the bandwidth and using 50% would
work fine.)

The underlying idea here is to make .torrents accessible to your average Firefox
downloader, who doesn't want to have to mess with helper apps, configuration,
bandwidth management, ratios etc., without breaking the reciprocal nature of
Bittorrent. Reread comment #1 for an expanded version of this explanation.

Gerv

I'm curious if bug 142255 (provide a way to prioritize connections) could in any
way benefit this.

Perhaps give BitTorrent a lower priority once downloading completes.  This would
encourage the user to keep bitTorrent going longer (won't impare performance),
while still providing some bits for other torrent downloaders.

Just a thought.
Personally, while the techie in me thinks it'd be nifty to have BT be an
alternate protocol, I agree that it doesn't make much sense practically. On the
other hand, making BT accessible to Joe Blow is /not/ a bad thing. If Firefox
could implement this as another means of downloading, then I think that would be
a very good thing indeed.
(In reply to comment #60)
> After reading both comments, it seems to me like you're both asking for the
> same thing but with different phrasing. Perhaps it is Gerv's use of the word
> "internal" that is causing confusion, but my understanding is that he is
> suggesting that the current download manager handle torrents, just as you
> suggested having a "sidebar" in the referenced paragraph.

Please read my old comment again and see I explicitly recommended a Mozilla
*plugin*, if anything, to handle BitTorrent download. Yes, I mentioned the
sidebar as a possible location for this plugin, but a plugin is definitely the
*opposite* of "internal".
(In reply to comment #61)

> Yes. I am suggesting that the Download manager handle torrents, and that the
> browser make it appear to the user as no more complicated than FTPing the
> file.

And the obvious question is: Why BitTorrent? Why not any of the other dozends of
protocols out there? Why is BitTorrent so important for a *webbrowser* that it
requires internal handling (as opposed to via a plugin)? It's not like I think
BitTorrent weren't important (or I wouldn't be a member of the dev team), but a
webbrowser definitely doesn't need it that badly.

> The underlying idea here is to make .torrents accessible to your average
> Firefox downloader, who doesn't want to have to mess with helper apps,
> configuration, bandwidth management, ratios etc., without breaking the
> reciprocal nature of Bittorrent.

Think about this: If your idea gets implemented (and let's assume it's
implemented well), how many users would use it? Your "average" web surfer
doesn't need BitTorrent at all. There is nothing my parents needs to download
which they can only get via BitTorrent. And of those who do need BitTorrent (one
third of all Mozilla users max, I'd say), the heavy users still won't use
Mozilla for it, since they all have their dedicated BitTorrent clients
configured the way they like it (upspeed and share ratio are too important
parameters to be left to default or automatic setting). So your targeted users
group is those who do need BitTorrent but only casually. That's a very small
group, I assure you. No way this could justify a bloat of the Mozilla core,
considering even calendar and IRC have been removed from the Mozilla core (and
very right so).

Frankly, I (and many I know) don't even use Mozilla's download manager for
HTTP/FTP downloads of large files (anything that takes more than 5 min, so the
exact size depends on the bandwidth) because of the lack of a resume function
(so wget comes to rescue). And with BitTorrent, there are only large files...
> Why BitTorrent?

Because it makes up about 1/3 of all the data traffic on the Internet, so could
therefore be said to be reasonably relevant to an application whose key function
is obtaining files across the Internet? ;-)
http://www.wired.com/wired/archive/13.01/bittorrent.html?tw=wn_story_top5

> Your "average" web surfer doesn't need BitTorrent at all. 

Not right now, perhaps. It's chicken and egg.

> There is nothing my parents needs to download which they can only get via 
> BitTorrent. 

Quite possibly not. But there are a lot of distributors out there (*cough*
mozilla.org *cough*) who would _love_ your parents, and 20,000,000 other people
just like them, to get their product using BitTorrent rather than FTP, because
they'd save a fortune in bandwidth. But they won't bother setting up a .torrent
until at least some of the visitors have clients which will download them
without leading to an increase in support calls.

> And of those who do need BitTorrent (one third of all Mozilla users max, I'd 
> say), 

One third of users is a mainstream feature. We have many features which are used
by a much smaller proportion than that, even in Firefox.

> (upspeed and share ratio are too important parameters to be left to default 
> or automatic setting)

I'd say we are aiming to make it possible for people to download files over
BitTorrent who wouldn't understand sharing ratios if you spent ten minutes
explaining them. :-)

Gerv

fwiw, I think for Gerv's proposed primary scenario (forgive me if I
mis-summarize), "Help distributors convert from HTTP to BT downloads to save
bandwidth without incurring extra user support costs", it's out of the question
to consider stealing (as in, using without informed consent) the user's
resources for someone else's benefit after the user's goal (download complete)
has been reached.

For caring users, prefs to continue seeding should be supported, perhaps with
discoverable UI (maybe akin to Malcolm's "Support" link) to get curious users to
effortlessly become such caring users.
Tuukka, you are aware that the user is using the resources of others to download
the file? Downloading from others without uploading the same amount could
according to your logic be considered stealing.

Something might happen with this bug request if my Google summer-of-code
application is accepted. I'm the author of http://libtorrent.rakshasa.no/,
Though i have no prior experience with the mozilla code-base nor XPCOM/XUL
programming.
Jari, the point of my comment was that
     a) shifting the user agent to transparently use the user's resources beyond
fulfilling the individual user's requests can reek of hijack; if its done, the
perceptional issue does need to be dealt with regardless of any moral
implications of the user's behaviour. ("Why does my Internet become teh slow
after downloading some files with Firefox, that doesn't happen with IE")
     b) the extent to which "giving back" is appropriate is not necessarily
constant across torrents

That said, I'm looking forward to it :)
Jari: I very much hope your application succeeds. I should note that if you
build BitTorrent support with libTorrent, it will need a licence change from GPL
to something compatible with our tri-licence. If you are the only contributor,
of course, that would not be a problem :-)

Email me if you need more info on this.

Gerv
I'm aware of the license issue, and will change it to LGPL if needed.
Jari: LGPL alone is also not compatible with the MPL. Compatible licenses
include the MPL/LGPL/GPL tri-licence, MPL/LGPL dual licence, and most variants
of BSD. As I said, email me if you need to discuss this.

Gerv
Hi everyone. Like Jari, I submitted a Google Summer of Code proposal for
implementing BitTorrent in Mozilla. My proposal was accepted, so I could only
assume that Jari unfortunately didn't get the job.

I have just finish trawling through various BitTorrent blog posts and bug
reports on bugzilla collecting whatever information and issues that were
discussed. It seems everything that's worth mentioning has already been
mentioned. Short of looking at actual Mozilla code, here are my thoughts on
implementing this:

-Initially, BT should only be supported in the download manager. Basically what
gerv said in comment #1.
-At this stage, I think an extension would be best. Eventually, I'd like to see
it merge into trunk.
-There will most likely be changes needed to necko, like to support throttling
and packet prioritising. Of course, these are optional, but if they're not done,
then we will have an inferior client. There might be other API changes needed as
well.
-The download manager UI really needs an overhaul.
-Downloads should survive between browser sessions...

With regards to download manager, throttling and downloads between sessions,
they seem to be on the agenda for Firefox 2.0. I think it would be good if there
is some sort of coordination with this and that effort.

So those are my first thoughts on implementing at the moment... too dizzy after
reading so much :)
fwiw some priority support was introduced by bug 278531
Ben Goodger has recently overhauled the download manager UI. If you are planning
significant changes, you need to coordinate with him.

Gerv
*** Bug 299866 has been marked as a duplicate of this bug. ***
Opera now supports BitTorrent in the new version.  See this URL:
http://www.betanews.com/article/Opera_Adds_BitTorrent_to_Web_Browser/1120670921
This development is now the mozdev.org "firepuddle" project:
http://firepuddle.mozdev.org/

Gerv
*** Bug 300766 has been marked as a duplicate of this bug. ***
I don't know if this has been mentioned already (78 posts is alot of reading),
but a good reason why this feature should be supported as an extension is so
that people can easily take it off if they want to use a different client for
BT. I do think it should be included with the standard version of FF though,
like the DOM inspector used to.

Also, as far as the using of bittorrent for webpages discussion goes... Has
anyone thought of offering their sites as a zip file for each page? Any embedded
objects (images, audio, flash, etc) could be included in this single file along
with the HTML and downloaded via bittorrent, then decompressed and used like a
regular site at render time. This may not be necessary for small/simple pages,
but popular sites with lots of pictures would definitely benefit when a high
traffic site, like Slashdot, links to it. Although Coral and Dijjer are already
trying to deal with this in their own ways...
Whiteboard: See comment 11 → [p-opera] See comment 11
I really disagree with this feature request, for 2 reasons. First, Firefox is
meant to be small and efficient, leaving most unnecessary features to extensions
and plugins. Adding bittorrent would not help normal users who never use BT, and
would not help power users since the implementation would most likely be very
basic and the power users would continue to use 3rd party programs anyways.

Second reason, BT is a very problematic protocol. It's hell with firewalls and
routers, because it needs both upload and download, at large port ranges,
leading to tons of user complaints about problems. Also most ISPs have bandwidth
limits, meaning many people decide not to use BT. Having it built in Firefox,
especially as the reporter suggest (being hidden and continue to upload past
100% without user consent) is a terrible terrible idea.

So no thanks, tons of bugs to work on anyways.

The bottom line is it's no more offensive than FTP (which we currently support).
 We could make the same arguments to drop FTP support from Firefox, since it is
a _browser_ not a download manager.


> The bottom line is it's no more offensive than FTP (which we currently support).
>  We could make the same arguments to drop FTP support from Firefox, since it is
> a _browser_ not a download manager.

No way!  FTP is core to the web browser -- always has been.  Moreover, passive
mode FTP has none of the firewall issues that plague BT.  I have to agree with
comment #81 completely.  The solution in comment #41 is only good for a very
small number of users.  How many normal people can and will configure their
router even when given a guide to follow?

By the way: Please, please don't spam this bug with any YAY or NAY comments! ;-)
While I personally think BitTorrent should be implemented as an extension (what
are the cons to those who DO use it? People who don't aren't bothered.)

But, I wanted to throw out a ***crazy*** idea. Just seeing if anyone is interested.

Imagine an extension that allows clicking on a .torrent file and it shows up in
the download manager, downloading and seeding (for a user-specified time
afterwards, say three hours). But!!! (this is the good part) If your download a
>300mb (or >1gb, whatever) file, it publishes that file (distributed tracker,
azureus-style) as a torrent using a DHT service such as OpenDHT for rendezvous.
Whenever anyone else somewhere else tries to download that file, it first looks
the tracker (looks the file up in the DHT). If there is none, it does the above
(it creates one). If there is one, it either:
-Downloads the file normally and then seeds
-Downloads the file using the torrent, seeding normally
depending on how fast the torrent would be (how many seeders, if there are few,
downloading normally would be much faster)

This would create a network of firefox-powered torrents of popular big files on
the web, reducing server load, completely automatically. Provisions would be
made so only popular files were torrent'ed, so billions of torrents didn't
clobber the DHT. Why isn't this possible? (not integrated into the browser, as
an extension!!!) I know someone will tell me I'm nuts, but really, why isn't
this possible.

Jacob
Jacob,

Like you said it's a crazy idea while technically it is possible to do.
But I believe this bug is about supporting the BitTorrent protocol in Firefox
not about all kinds of neat extensions about BitTorrent.
Gotcha.
Blocks: 320251
Interesting...

http://allpeers.com/more_f.htm

AllPeers is a free extension which combines the strength of Firefox and the efficiency of BitTorrent to transform your favorite browser into a media sharing powerhouse.

Regain control! You decide which media files you want to share with whom and to maximise your privacy, communications are encrypted. 
This should probably depend on bug 230870.
I really do not like Allpeers. There is a project in the planning phase called "Firestorm". It will be an extension, which lets firefox use bittorrent.
(In reply to comment #89)
> I really do not like Allpeers. There is a project in the planning phase called
> "Firestorm". It will be an extension, which lets firefox use bittorrent.

AllPeers is non-free anyhow. Can you post some information about Firestorm? The 2 efforts I found via google to bring BT support to Mozilla have been abandoned.

They are:
http://firepuddle.mozdev.org/
and http://moztorrent.mozdev.org/

The first one has a good bit of coding done (and it would seem as though it was nearly basically working at a time - see the download page). I'd seriously look at making it work with trunk, but it apparently only runs on Windows which I don't have access to and it's written in C++, where I only code in Javascript w/ XPConnect.

This would also be useful for other XULapps btw, such as Songbird. Votes++
Firestorm project should have their initial release in the next cuple of days. This is probably the first promising bittorrent extension project I've seen.

http://firestorm.mozdev.com/

Maybe Mozilla could be able to help maintain the extension. It is all written in python XPcon.
Also, <a "href=http://www.foxtorrent.com/">foxtorrent</a> is an extension that does this.
Just a quick note that we now have a fully fledged BT client in AllPeers (see http://www.techcrunch.com/2007/09/09/allpeers-preview-for-techcrunch-readers/). We're definitely motivated to extend and improve this. The whole implementation is open source and based on the Mozilla stack (NSPR, NSS, XPCOM, etc.).
Couple of questions (I already contacted the Q-A contact on this bug but he couldn't help):

1) Has a decision been made to add bittorrent support to firefox or have it as an extension?

2) Is there a possibility that a patch would be accepted if it requires the boost library? (I have been suggested to ask this on .platform and I'll do if I don't get an answer here).
I think it's unlikely a patch would be accepted without having first been proved as an extension, so I would encourage anyone with interest to look at doing that first.

Gerv
Let me just reiterate what I said in https://bugzilla.mozilla.org/show_bug.cgi?id=236755#c93 : we have a full BT implementation that is open source and based on NSS. It's kind of bound up with the rest of our framework, which probably isn't going to get into the Mozilla proper any time soon, but if someone is contemplating a truly Mozilla-compatible BT suitable for inclusion in Firefox, I'd strongly encourage you to take a look. I'd be very open to discussions about how to factor out the BT functionality from other AllPeers dependencies.
would be nice have supported torrent protocol in HTML5 video tag:
<video src="torrent://">
(In reply to comment #99)
> would be nice have supported torrent protocol in HTML5 video tag:
> <video src="torrent://">

Do you realize how long it would take to display such a page ? This bug is about the download mechanism, where you let the download run for hours if needed.

See bug 203571 comment 13 why this would be a bad idea.
I'm talking just about video source as bittorent, not HTML pages or jpeg.
Video traffic is a presently typical problem of VoD services and internet providers.
Will be very nice to have in Mozilla integrated player support for play bittorent video during download. Yes, and it's technically possible.

Inspired by Joost for example, and others internet p2p video services.
(In reply to comment #101)
Sorry "Comsultia", but IMO it's a nonsense. Embedding is used if the download speed is high - and p2p is not always fast - and/or you want the user can only see the video, and not store it on HD.

Furthermore you have not read carefully bug 203571 comment 13:

> [...] it's not a good idea to bind this embedding process to BitTorrent, 
> because every "BitTorrent connection" has a lifespan which need to be 
> specifed by the user himself. A file keeps being uploaded after its download 
> completes within BitTorrent, until the user decides to "finish" this file. If 
> a video embedded into a webpage is downloaded via BitTorrent, when should the 
> upload of this same video stop? Immediately after the download completes? Or 
> when the user leaves the website? Both are rather too soon to keep the file 
> healthy alive.
Assignee: file-handling → nobody
QA Contact: ian → file-handling
Blocks: 596839
(In reply to Comsultia, Ltd. from comment #99)
> would be nice have supported torrent protocol in HTML5 video tag:
> <video src="torrent://">

I would like to see this too, but also supporting the new "magnet:" style torrent links.

Discussion proposal, answering questions raised by bug 203571 comment 13:

I think, regardless of protocol, referencing *any* file over a certain size within a video (or img, etc) element could result in the opening of the download manager, with that content being added to the active downloads (giving the user some opportunity to cancel the operation), ie, what happens if someone does <video src="http://2_gigabyte_video.webm"> on a HTTP/1.0 server that doesn't support range requests?  I would expect any large content being downloaded could be shown in the download manager and also play within the page element as that data becomes available.  I would expect such downloads to be automatically be terminated if the user navigates away from the download-spawning page.

I think, again regardless of protocol, the Firefox video UI displayed within the page has/needs some way to provide status for buffering, streaming stalls, etc, and the page level torrent UI could be handled using the same mechanism.  I don't think elongated startup display times would be a problem as long as the user is provided status information ("connecting to server/tracker...", "downloading/buffering...", "estimated time till playback begins: unknown/1 minute", or some such).

Similarly, I would expect referencing a torrent file from a video tag to result the download manager being opened and having that torrent added to it's active downloads.  I would expect the embedded torrent client to have user prefs for seeding/sharing/ratio/lifespan, like any other torrent download software.  I would expect the embedded client to be patched with the ability to attempt to download chunks somewhat in order (ie, try to download the beginning of the video first).

If there is a 10MB video on a page, regardless of whether you watch the whole thing or just the first 10%/1MB before navigating away from the page, I would expect the torrent client to seed the content you did download until you reach the regularly configured share ratio.  And, again, I would not expect any remaining content to be downloaded after you navigate away from the page, unless you resume the downloaded manually within the manager, perhaps so you can save the content upon completion for later viewing.

Video content is becoming increasingly popular on the web, and users today are confined to big providers like YouTube who can afford the servers and bandwidth required to support distributing such content.  This restricts the ability of small individuals to create and distribute large multimedia content.  While embedded torrent support might not be as seamless/ideal as other mechanisms, it does give *everyone* the freedom to become their own YouTube, and I hear that's what Firefox and the Open Web are all about.
Perhaps we can jump-start this bug back into actionable-land if we narrow the scope... what would it take to have basic, functional BitTorrent support for downloads? Not HTML embedded content, just downloads. I think the idea of supporting HTML5 video downloads is interesting, and worth pursuing, but if we set our sights on that we might never get off the ground at all (as evidenced by this bug being 9 years old, with basically zero progress).

We would like to use this for Firefox's built-in updater over in bug 596839. It has the potential to save Mozilla a *lot* of money. My gut reaction is that this is a feature which could pay for itself, fast.

So... what kind of time investment are we talking about here?
addon
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.