Below are diffs I have questions about based on the context set above. I didn't do a full review of the changes (you must be beat after making 750k worth of diffs :-)).
Index: dom/src/jsurl/nsJSProtocolHandler.cpp
===================================================================
RCS file: /cvsroot/mozilla/dom/src/jsurl/nsJSProtocolHandler.cpp,v
retrieving revision 1.55
retrieving revision 1.55.34.1
diff -u -r1.55 -r1.55.34.1
--- nsJSProtocolHandler.cpp 2000/09/13 23:50:39 1.55
+++ nsJSProtocolHandler.cpp 2001/01/23 20:35:59 1.55.34.1
@@ -492,11 +492,6 @@
nsCOMPtr<nsIStreamIOChannel> channel;
rv = NS_NewStreamIOChannel(getter_AddRefs(channel),
uri, thunk);
- // If the resultant script evaluation actually
does return a value, we
- // treat it as html. XXXbe see <plaintext>
comment above
- if (NS_SUCCEEDED(rv)) {
- rv = channel->SetContentType("text/html");
- }
if (NS_SUCCEEDED(rv)) {
rv = thunk->Init(uri,
channel);
}
You've pulled the default mime type from the
JS handler. I don't know the JS handler at all, but I'm concerned that
consumers are going to get ahold of a channel/request before the type has
been set, and that this will wreak havoc. Do JS loads happen via the uriLoader?
If so, are you assuming (probably correctly) that the unknowndecoder will
resolve the type to text/html?
Index: extensions/psm-glue/public/psm-glue.js
===================================================================
RCS file: /cvsroot/mozilla/extensions/psm-glue/public/psm-glue.js,v
retrieving revision 1.1
retrieving revision 1.1.60.1
diff -u -r1.1 -r1.1.60.1
--- psm-glue.js 2000/03/28 12:24:17 1.1
+++ psm-glue.js 2001/01/23 18:23:53 1.1.60.1
@@ -9,3 +9,5 @@
pref("security.warn_leaving_secure",
true);
pref("security.warn_viewing_mixed",
true);
pref("security.warn_submit_insecure", true);
+
+pref("security.ui.enable", true);
Just a sanity check. There are some PSM changes
(above is just one) in this branch, should they be?
Index: layout/xml/document/src/nsXMLDocument.cpp
===================================================================
RCS file: /cvsroot/mozilla/layout/xml/document/src/nsXMLDocument.cpp,v
retrieving revision 1.94
retrieving revision 1.94.2.1
diff -u -r1.94 -r1.94.2.1
...
@@ -375,8 +381,10 @@
rv = aChannel->GetURI(getter_AddRefs(aUrl));
if (NS_FAILED(rv)) return rv;
- rv = aChannel->GetContentType(&aContentType);
-
+ nsCOMPtr<nsIMIMEService> MIMEService (do_GetService(NS_MIMESERVICE_CONTRACTID,
&rv));
+ if (NS_FAILED(rv)) return rv;
+ rv = MIMEService->GetTypeFromURI(aUrl, &aContentType);
+
if (NS_SUCCEEDED(rv)) {
if ( 0 == PL_strcmp(aContentType, "text/html"))
{
bIsHTML = PR_TRUE;
The MIMEService simply maps a file extension against
a table of extension to mime type mappings. So, if the URI is http://www.foo.com/bar
, and bar is actually an xml file, before this change, the server would
have likely set the content type in the channel to "text/xml." Your change
will result in the "unknown/type" mime type to be set in aContentType.
If this load goes through the uriloader, and eventually gets to the unknowndecoder,
the unknown content type handler dialog will be thrown because the unkonwndecoder
doesn't decode xml.
Index: rdf/content/src/nsXULDocument.cpp
===================================================================
RCS file: /cvsroot/mozilla/rdf/content/src/nsXULDocument.cpp,v
....
-PlaceholderChannel::~PlaceholderChannel()
+PlaceHolderRequest::~PlaceHolderRequest()
{
if (--gRefCnt == 0) {
NS_IF_RELEASE(gURI);
@@ -759,7 +731,9 @@
// StartDocumentLoad() before the channel's
content type has been
// detected.
nsXPIDLCString contentType;
- (void) aChannel->GetContentType(getter_Copies(contentType));
+ nsCOMPtr<nsIMIMEService> MIMEService (do_GetService(NS_MIMESERVICE_CONTRACTID,
&rv));
+ if (NS_FAILED(rv)) return rv;
+ rv = MIMEService->GetTypeFromURI(mDocumentURL,
getter_Copies(contentType));
Same problem as above. The MIMEService may not
be able to find a content type that the server would have otherwise set.
Index: xpfe/components/xfer/src/nsStreamTransfer.cpp
===================================================================
RCS file: /cvsroot/mozilla/xpfe/components/xfer/src/nsStreamTransfer.cpp,v
retrieving revision 1.28
retrieving revision 1.28.10.1
diff -u -r1.28 -r1.28.10.1
--- nsStreamTransfer.cpp 2000/10/28 22:17:51 1.28
+++ nsStreamTransfer.cpp 2001/01/23 20:32:37 1.28.10.1
@@ -35,6 +35,10 @@
#include "nsIAllocator.h"
#include "nsIFileStream.h"
+#include "nsCExternalHandlerService.h"
+#include "nsIMIMEService.h"
+#include "nsMimeTypes.h"
+
// {BEBA91C0-070F-11d3-8068-00600811A9C3}
#define NS_STREAMTRANSFER_CID \
{ 0xbeba91c0, 0x70f, 0x11d3, { 0x80, 0x68,
0x0, 0x60, 0x8, 0x11, 0xa9, 0xc3 } }
@@ -80,10 +84,20 @@
// Get content type and suggested name from input channel
in this case.
NS_IMETHODIMP
nsStreamTransfer::SelectFileAndTransferLocation( nsIChannel
*aChannel, nsIDOMWindowInternal *parent ) {
- // Content type comes straight from channel.
+
+ nsCOMPtr<nsIURI> uri;
+ nsresult rv = aChannel->GetURI( getter_AddRefs(
uri ) );
+ if (NS_FAILED(rv)) return rv;
+
nsXPIDLCString contentType;
- aChannel->GetContentType( getter_Copies( contentType
) );
+ nsCOMPtr<nsIMIMEService> MIMEService (do_GetService(NS_MIMESERVICE_CONTRACTID,
&rv));
+ if (NS_FAILED(rv)) return rv;
+ rv = MIMEService->GetTypeFromURI(uri, getter_Copies(contentType));
+ if (NS_FAILED(rv)) {
+ contentType = UNKNOWN_CONTENT_TYPE;
+ }
+
Same as the previous two.
The order of precedence on content type resolving
(everywhere in the system) is this:
Server header (applies to HTTP only as other
protocols we support don't provide content type info)
File extension mapping (or Internet Config on
the mac)
From the changes above, as far as I can tell, you've fliped the precedence which will cause problems.
Jud
