Граф коммитов

28 Коммитов

Автор SHA1 Сообщение Дата
dveditz%cruzio.com ab1ad1555f bug 263546: move external protocol warning down a level, r=jsr,sr=darin 2004-10-25 07:46:01 +00:00
cbiesinger%web.de 9c6451ce9e add a way to get an application description for a given externally-handled
scheme, and use it in the confirmation dialog that asks whether to launch such
links.
bug 258802
windows and cross-platform part: r=ere sr=neil,bz
linux part: r=bz sr=bryner
2004-10-16 13:46:17 +00:00
cbiesinger%web.de 85a73f60f5 fixing bustage 2004-10-03 17:19:08 +00:00
cbiesinger%web.de dce292d250 259084 some cleanup after bug 173010 r=bz sr=darin 2004-10-03 17:06:57 +00:00
dveditz%cruzio.com 841d71848f bug 173010 prompt before launching external protocol handler,r=mscott,sr=darin/jst 2004-09-10 23:24:49 +00:00
bzbarsky%mit.edu 1b90bf9200 Setting location to a mailto: URI should not throw if there is a system mailto:
handler.  Bug 236589, r=biesi, sr=darin
2004-07-29 23:58:59 +00:00
bzbarsky%mit.edu 71db5adf33 Fix problem with the external protocol channel that makes it return a null
originalURI and cause crashes.  Bug 241300, r=biesi, sr=darin
2004-07-15 20:20:50 +00:00
bzbarsky%mit.edu 5bb05f7876 Blocked protocols should still allow URI creation; they should just fail
channel creation.  Bug 244220, r+sr=darin
2004-05-21 00:28:52 +00:00
gerv%gerv.net aa835b77c5 Bug 236613: change to MPL/LGPL/GPL tri-license. 2004-04-17 16:52:41 +00:00
cavin%netscape.com 47ad5ffffc Fix for 183111. Added nsIExternalProtocolHandler interface and method handlerExists in netwerk/bae/public to be used by mozTXTToHTMLConv. Also treated 0xA0 as space in mozTXTToHTMLConv. r=darin, sr=sspitzer. 2003-02-27 22:46:42 +00:00
dbaron%dbaron.org f2cd5e3e66 Bug 178643: Remove uses of NS_INIT_ISUPPORTS, since it is no longer needed. r=timeless sr=jag 2003-01-08 23:19:20 +00:00
timeless%mozdev.org 8fc5168183 Bug 186723 external protocol handler NewURI doesn't check to see if SetSpec failed..
patch by andersma@luther.edu r=timeless sr=darin
2003-01-08 20:32:14 +00:00
bzbarsky%mit.edu 4d094c04fc Make nsILinkHandler take uris instead of strings. Bug 176904, r=darin, sr=jst 2002-11-20 00:44:26 +00:00
dougt%netscape.com c5e8f896cd 166917. Clean up xpcom SDK includes. r=rpotts@netscape.com, sr=alecf@netscape.com, a=rjesup@wgate.com 2002-09-07 17:13:19 +00:00
darin%netscape.com 040ddbbf28 cleaning up documentation, marking some interfaces frozen, and splitting
up some interfaces into separate IDL files (b=124465)
reviewed by dougt and bbaetz
2002-05-03 07:49:43 +00:00
darin%netscape.com 819ce1f98f b=128508 "freeze nsIChannel nsIRequest" r=gagan, sr=rpotts, a=asa 2002-03-20 22:50:33 +00:00
darin%netscape.com 026dda9f95 fixes bug 124042 "support internationalized URIs" r=dougt, sr=alecf, a=asa 2002-03-06 07:48:55 +00:00
jaggernaut%netscape.com fdc4078bc4 Bug 100476: Convert uses of member functions ToNewUnicode, ToNewCString and ToNewUTF8String to their global versions and remove support from nsCString and nsString. r=dbaron, rs=scc 2001-09-29 08:28:41 +00:00
darin%netscape.com c95cf54bdc checking bbaetz's patch for bug 89500 "SOCKS: only http|https re-directted in (post Mozilla 0.9.2)"
patch=bbaetz, r=dougt, sr=darin
2001-09-13 02:21:05 +00:00
andreas.otte%primus-online.de c6853783af bug 40670 [URL: resolution of protocol:/path] checking in the groundwork to have an easy fix if we ever decide to support these kind of deprecated relative urls. For that a new attribute URIType is added to nsIProtocolHandler and its implementations to store some protocol/scheme dependend information to have enough information to allow correct parsing. r=darin@netscape.com sr=rpotts@netscape.com 2001-08-07 20:42:57 +00:00
dougt%netscape.com 9174af6517 Fixes bug 83401. r=gagan, darin, sr=vidur, a=blizzard. Add port blacklisting to necko 2001-06-06 00:10:09 +00:00
pavlov%netscape.com 2b64daaf18 fixing build bustage 2001-04-10 07:10:30 +00:00
darin%netscape.com 41efbc6217 Necko API changes, bug 74221. r=valeski, sr=rpotts. 2001-04-10 06:01:08 +00:00
dougt%netscape.com eab041f43f Relanding Necko Changes.
Revising nsIChannel to allow for overlapped i/o. This consists of three parts:

1. Factoring nsIChannel into a protocol specific part, the nsIChannel, and a socket specific, the nsITransport.
2. Derive the nsIChannel from a nsIRequest.
2. Changes the notification system from necko and the URILoader to pass the nsIRequest interface instead of nsIChannel interface.

This goal stems from wanting to be able to have active AsyncRead and AsyncWrite operations on nsSocketTransport.
This is desired because it would greatly simplify the task of maintaining persistent/reusable socket connections
for FTP, HTTP, and Imap (and potentially other protocols). The problem with the existing nsIChannel interface is
that it does not allow one to selectively suspend just one of the read or write operations while keeping the other active.

r=darin@netscape.com
sr=rpotts@netscape.com
2001-02-21 20:38:08 +00:00
disttsc%bart.nl 76fbedadc5 Back out dougt's channel changes 2001-02-12 03:14:23 +00:00
dougt%netscape.com 69415757ab Revising nsIChannel to allow for overlapped i/o. This consists of three parts:
1. Factoring nsIChannel into a protocol specific part, the nsIChannel, and a socket specific, the nsITransport.
2. Derive the nsIChannel from a nsIRequest.
2. Changes the notification system from necko and the URILoader to pass the nsIRequest interface instead of nsIChannel interface.

This goal stems from wanting to be able to have active AsyncRead and AsyncWrite operations on nsSocketTransport.
This is desired because it would greatly simplify the task of maintaining persistent/reusable socket connections
for FTP, HTTP, and Imap (and potentially other protocols).  The problem with the existing nsIChannel interface is
that it does not allow one to selectively suspend just one of the read or write operations while keeping the other active.

The full details of the change on written up in the netlib newsgroup.

r=darin@netscape.com
sr=rpotts@netscape.com
2001-02-10 00:16:26 +00:00
mscott%netscape.com fa94170c0b Bug #63193 --> the external protocol handler should only return a url or a new channel if we really do
have an external app that can handle the url. otherwise return NS_ERROR_UNKNOWN_PROTOCOL so we'll throw up an alert
dialog later on.
sr=sspizter
2001-02-07 05:24:27 +00:00
mscott%netscape.com 7a3ab1efac Bug #63193 --> add these two new files for a default protocol handler which will kick urls out to the OS
sr=rpotts
2001-02-07 01:21:58 +00:00