Bug 1224046 - Remove <base href> from directory listings. r=mcmanus
authorMike Hommey <mh+mozilla@glandium.org>
Thu, 12 Nov 2015 18:00:15 +0900
changeset 273026 19e419ab3792fa5aad9f531364e72827ea01d34c
parent 273025 d9251b9fb03efe56b7215ec6e2af2b696c9a8723
child 273027 5e13dfe46dc43f1a9a4086dce83e6b50fcbcdb95
push id68137
push usermh@glandium.org
push dateTue, 17 Nov 2015 23:43:06 +0000
treeherdermozilla-inbound@19e419ab3792 [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
bugs1224046, 358128, 1184387
first release with
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
last release without
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
Bug 1224046 - Remove <base href> from directory listings. r=mcmanus There was an attempt to remove it in bug 358128, but that was backed out because of FTP listings, where e.g. a 'mozilla' link on the ftp://ftp.mozilla.org/pub listing (without a trailing slash) would go to ftp://ftp.mozilla.org/pubmozilla instead of ftp://ftp.mozilla.org/pub/mozilla. It appears that versions of Firefox at the time of that bug wouldn't "redirect" directories to the same url with a trailing slash when one was not provided. It also appears that current versions of Firefox *do* "redirect" in such a way, such that the <base href> is now unnecessary. That <base href> prevents links from resource://... directory listings to work properly because of security contraints added in bug 1184387, as they force links to go to a jar/file url instead of the equivalent resource://... url, which removing <base href> allows.
--- a/netwerk/streamconv/converters/nsIndexedToHTML.cpp
+++ b/netwerk/streamconv/converters/nsIndexedToHTML.cpp
@@ -528,40 +528,16 @@ nsIndexedToHTML::DoOnStartRequest(nsIReq
     if (NS_FAILED(rv)) return rv;
     // we want to convert string bundle to NCR
     // to ensure they're shown in any charsets
     AppendNonAsciiToNCR(title, buffer);
-    // If there is a quote character in the baseUri, then
-    // lets not add a base URL.  The reason for this is that
-    // if we stick baseUri containing a quote into a quoted
-    // string, the quote character will prematurely close
-    // the base href string.  This is a fall-back check;
-    // that's why it is OK to not use a base rather than
-    // trying to play nice and escaping the quotes.  See bug
-    // 358128.
-    if (!baseUri.Contains('"'))
-    {
-        // Great, the baseUri does not contain a char that
-        // will prematurely close the string.  Go ahead an
-        // add a base href.
-        buffer.AppendLiteral("<base href=\"");
-        nsAdoptingCString htmlEscapedUri(nsEscapeHTML(baseUri.get()));
-        buffer.Append(htmlEscapedUri);
-        buffer.AppendLiteral("\" />\n");
-    }
-    else
-    {
-        NS_ERROR("broken protocol handler didn't escape double-quote.");
-    }
     nsCString direction(NS_LITERAL_CSTRING("ltr"));
     nsCOMPtr<nsIXULChromeRegistry> reg =
     if (reg) {
       bool isRTL = false;
       reg->IsLocaleRTL(NS_LITERAL_CSTRING("global"), &isRTL);
       if (isRTL) {