bzbarsky@mit.edu
|
502c4c7607
|
Fix leak bug 391978. r=biesi, sr=dmose, a=sayrer
|
2007-11-08 22:13:26 -08:00 |
dmose@mozilla.org
|
10f8641377
|
Fix web based protocol handlers to work from link clicks in addition to the URL bar (bug 383396), r=biesi, sr=sicking
|
2007-06-15 14:43:51 -07:00 |
dmose@mozilla.org
|
12f5a83e26
|
Implement backend changes for web-based protocol handlers a la WhatWG HTML5 draft (bug 380415). r=cbiesinger@gmx.at, sr=jonas@sicking.cc
|
2007-05-25 08:17:44 -07:00 |
bzbarsky%mit.edu
|
bb3844e6d4
|
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
|
f7f3cb2736
|
Bug 236613: change to MPL/LGPL/GPL tri-license.
|
2004-04-17 16:52:41 +00:00 |
cbiesinger%web.de
|
330498be5a
|
230970
nsExternalAppHandler needs no virtual functions
also, w/o bug: nsExternalHelperAppService doesn't require threadsafe addref/release
r=bzbarsky sr=darin
|
2004-01-16 18:22:55 +00:00 |
cavin%netscape.com
|
32e275f48d
|
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 |
mscott%netscape.com
|
7d14d6aaaa
|
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
|
7acbc39ac7
|
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 |