2018-11-30 22:52:05 +03:00
|
|
|
/* -*- Mode: C++; tab-width: 2; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
|
2012-05-21 15:12:37 +04:00
|
|
|
/* This Source Code Form is subject to the terms of the Mozilla Public
|
|
|
|
* License, v. 2.0. If a copy of the MPL was not distributed with this
|
|
|
|
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
|
1999-11-23 15:13:33 +03:00
|
|
|
|
2010-03-11 08:33:00 +03:00
|
|
|
#include "mozilla/chrome/RegistryMessageUtils.h"
|
2014-10-07 21:29:40 +04:00
|
|
|
#include "mozilla/dom/ContentParent.h"
|
2016-08-23 07:09:32 +03:00
|
|
|
#include "mozilla/Unused.h"
|
2010-03-11 08:33:00 +03:00
|
|
|
|
1999-11-23 15:13:33 +03:00
|
|
|
#include "nsResProtocolHandler.h"
|
2000-06-09 11:51:13 +04:00
|
|
|
#include "nsIIOService.h"
|
|
|
|
#include "nsIFile.h"
|
2015-07-07 05:17:00 +03:00
|
|
|
#include "nsNetCID.h"
|
2001-09-10 04:42:50 +04:00
|
|
|
#include "nsNetUtil.h"
|
2002-09-13 23:32:45 +04:00
|
|
|
#include "nsURLHelper.h"
|
2007-02-26 19:57:48 +03:00
|
|
|
#include "nsEscape.h"
|
1999-11-23 15:13:33 +03:00
|
|
|
|
2010-06-23 23:59:59 +04:00
|
|
|
#include "mozilla/Omnijar.h"
|
|
|
|
|
2015-06-04 01:25:57 +03:00
|
|
|
using mozilla::LogLevel;
|
2015-11-02 08:53:26 +03:00
|
|
|
using mozilla::Unused;
|
2014-10-07 21:29:40 +04:00
|
|
|
using mozilla::dom::ContentParent;
|
|
|
|
|
Bug 1225384 - Change how the default resource "host names" are handled. r=michal
The meaning of resource:///, resource://app/ and resource://gre/ needs to
remain constant. Unfortunately, the model of the resource protocol handler
is that it is possible to set substitutions that change their meaning.
So, we forbid setting overwriting the substitutions for those three
special "host names".
Unfortunately, with e10s, the full list of substitutions is also sent to
the content process, which then sets substitutions, making it harder to
know in which cases SetSubstitution is valid for those three "host names"
or not.
So instead of trying to find the right heuristics, use the recently added
SubstitutingProtocolHandler::ResolveSpecialCases API to handle the three
"host names" instead of storing them as "normal" substitutions.
Still actively reject SetSubstitution with the three special "host names"
so as to find issues such as bug 1224000 instead of allowing the chrome
manifest entry and have it silently ignored.
Additionally, make GetSubstitution return the URIs for the three special
"host names" through GetSubstitutionInternal, replacing what was originally
added in bug 257162. Those changes from bug 257162 relied on the
resource:app string being handled by nsXREDirProvider::GetFile, but that was
removed in bug 620931, effectively making that code now in
GetSubstitutionInternal useless.
2015-11-17 11:21:03 +03:00
|
|
|
#define kAPP "app"
|
|
|
|
#define kGRE "gre"
|
2019-02-25 18:38:21 +03:00
|
|
|
#define kAndroid "android"
|
2018-11-30 13:46:48 +03:00
|
|
|
|
2019-05-28 16:46:17 +03:00
|
|
|
mozilla::StaticRefPtr<nsResProtocolHandler> nsResProtocolHandler::sSingleton;
|
|
|
|
|
|
|
|
already_AddRefed<nsResProtocolHandler> nsResProtocolHandler::GetSingleton() {
|
|
|
|
if (!sSingleton) {
|
|
|
|
RefPtr<nsResProtocolHandler> handler = new nsResProtocolHandler();
|
|
|
|
if (NS_WARN_IF(NS_FAILED(handler->Init()))) {
|
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
sSingleton = handler;
|
|
|
|
ClearOnShutdown(&sSingleton);
|
|
|
|
}
|
|
|
|
return do_AddRef(sSingleton);
|
|
|
|
}
|
|
|
|
|
2003-09-13 21:55:56 +04:00
|
|
|
nsresult nsResProtocolHandler::Init() {
|
2001-09-20 05:32:16 +04:00
|
|
|
nsresult rv;
|
Bug 1225384 - Change how the default resource "host names" are handled. r=michal
The meaning of resource:///, resource://app/ and resource://gre/ needs to
remain constant. Unfortunately, the model of the resource protocol handler
is that it is possible to set substitutions that change their meaning.
So, we forbid setting overwriting the substitutions for those three
special "host names".
Unfortunately, with e10s, the full list of substitutions is also sent to
the content process, which then sets substitutions, making it harder to
know in which cases SetSubstitution is valid for those three "host names"
or not.
So instead of trying to find the right heuristics, use the recently added
SubstitutingProtocolHandler::ResolveSpecialCases API to handle the three
"host names" instead of storing them as "normal" substitutions.
Still actively reject SetSubstitution with the three special "host names"
so as to find issues such as bug 1224000 instead of allowing the chrome
manifest entry and have it silently ignored.
Additionally, make GetSubstitution return the URIs for the three special
"host names" through GetSubstitutionInternal, replacing what was originally
added in bug 257162. Those changes from bug 257162 relied on the
resource:app string being handled by nsXREDirProvider::GetFile, but that was
removed in bug 620931, effectively making that code now in
GetSubstitutionInternal useless.
2015-11-17 11:21:03 +03:00
|
|
|
rv = mozilla::Omnijar::GetURIString(mozilla::Omnijar::APP, mAppURI);
|
2011-02-25 14:53:36 +03:00
|
|
|
NS_ENSURE_SUCCESS(rv, rv);
|
Bug 1225384 - Change how the default resource "host names" are handled. r=michal
The meaning of resource:///, resource://app/ and resource://gre/ needs to
remain constant. Unfortunately, the model of the resource protocol handler
is that it is possible to set substitutions that change their meaning.
So, we forbid setting overwriting the substitutions for those three
special "host names".
Unfortunately, with e10s, the full list of substitutions is also sent to
the content process, which then sets substitutions, making it harder to
know in which cases SetSubstitution is valid for those three "host names"
or not.
So instead of trying to find the right heuristics, use the recently added
SubstitutingProtocolHandler::ResolveSpecialCases API to handle the three
"host names" instead of storing them as "normal" substitutions.
Still actively reject SetSubstitution with the three special "host names"
so as to find issues such as bug 1224000 instead of allowing the chrome
manifest entry and have it silently ignored.
Additionally, make GetSubstitution return the URIs for the three special
"host names" through GetSubstitutionInternal, replacing what was originally
added in bug 257162. Those changes from bug 257162 relied on the
resource:app string being handled by nsXREDirProvider::GetFile, but that was
removed in bug 620931, effectively making that code now in
GetSubstitutionInternal useless.
2015-11-17 11:21:03 +03:00
|
|
|
rv = mozilla::Omnijar::GetURIString(mozilla::Omnijar::GRE, mGREURI);
|
2011-02-25 14:53:36 +03:00
|
|
|
NS_ENSURE_SUCCESS(rv, rv);
|
2018-11-30 13:46:48 +03:00
|
|
|
|
Bug 1225384 - Change how the default resource "host names" are handled. r=michal
The meaning of resource:///, resource://app/ and resource://gre/ needs to
remain constant. Unfortunately, the model of the resource protocol handler
is that it is possible to set substitutions that change their meaning.
So, we forbid setting overwriting the substitutions for those three
special "host names".
Unfortunately, with e10s, the full list of substitutions is also sent to
the content process, which then sets substitutions, making it harder to
know in which cases SetSubstitution is valid for those three "host names"
or not.
So instead of trying to find the right heuristics, use the recently added
SubstitutingProtocolHandler::ResolveSpecialCases API to handle the three
"host names" instead of storing them as "normal" substitutions.
Still actively reject SetSubstitution with the three special "host names"
so as to find issues such as bug 1224000 instead of allowing the chrome
manifest entry and have it silently ignored.
Additionally, make GetSubstitution return the URIs for the three special
"host names" through GetSubstitutionInternal, replacing what was originally
added in bug 257162. Those changes from bug 257162 relied on the
resource:app string being handled by nsXREDirProvider::GetFile, but that was
removed in bug 620931, effectively making that code now in
GetSubstitutionInternal useless.
2015-11-17 11:21:03 +03:00
|
|
|
// mozilla::Omnijar::GetURIString always returns a string ending with /,
|
|
|
|
// and we want to remove it.
|
|
|
|
mGREURI.Truncate(mGREURI.Length() - 1);
|
|
|
|
if (mAppURI.Length()) {
|
|
|
|
mAppURI.Truncate(mAppURI.Length() - 1);
|
|
|
|
} else {
|
|
|
|
mAppURI = mGREURI;
|
2011-02-25 14:53:36 +03:00
|
|
|
}
|
2018-11-30 13:46:48 +03:00
|
|
|
|
2019-02-25 18:38:21 +03:00
|
|
|
#ifdef ANDROID
|
|
|
|
rv = GetApkURI(mApkURI);
|
|
|
|
#endif
|
|
|
|
|
2003-09-13 21:55:56 +04:00
|
|
|
// XXXbsmedberg Neil wants a resource://pchrome/ for the profile chrome dir...
|
|
|
|
// but once I finish multiple chrome registration I'm not sure that it is
|
|
|
|
// needed
|
2018-11-30 13:46:48 +03:00
|
|
|
|
2008-10-01 09:15:58 +04:00
|
|
|
// XXX dveditz: resource://pchrome/ defeats profile directory salting
|
|
|
|
// if web content can load it. Tread carefully.
|
2018-11-30 13:46:48 +03:00
|
|
|
|
2004-09-07 22:59:07 +04:00
|
|
|
return rv;
|
1999-11-23 15:13:33 +03:00
|
|
|
}
|
|
|
|
|
2019-02-25 18:38:21 +03:00
|
|
|
#ifdef ANDROID
|
|
|
|
nsresult nsResProtocolHandler::GetApkURI(nsACString& aResult) {
|
|
|
|
nsCString::const_iterator start, iter;
|
|
|
|
mGREURI.BeginReading(start);
|
|
|
|
mGREURI.EndReading(iter);
|
|
|
|
nsCString::const_iterator start_iter = start;
|
|
|
|
|
|
|
|
// This is like jar:jar:file://path/to/apk/base.apk!/path/to/omni.ja!/
|
|
|
|
bool found = FindInReadable(NS_LITERAL_CSTRING("!/"), start_iter, iter);
|
|
|
|
NS_ENSURE_TRUE(found, NS_ERROR_UNEXPECTED);
|
|
|
|
|
|
|
|
// like jar:jar:file://path/to/apk/base.apk!/
|
|
|
|
const nsDependentCSubstring& withoutPath = Substring(start, iter);
|
|
|
|
NS_ENSURE_TRUE(withoutPath.Length() >= 4, NS_ERROR_UNEXPECTED);
|
|
|
|
|
|
|
|
// Let's make sure we're removing what we expect to remove
|
|
|
|
NS_ENSURE_TRUE(Substring(withoutPath, 0, 4).EqualsLiteral("jar:"),
|
|
|
|
NS_ERROR_UNEXPECTED);
|
|
|
|
|
|
|
|
// like jar:file://path/to/apk/base.apk!/
|
|
|
|
aResult = ToNewCString(Substring(withoutPath, 4));
|
|
|
|
|
|
|
|
// Remove the trailing /
|
|
|
|
NS_ENSURE_TRUE(aResult.Length() >= 1, NS_ERROR_UNEXPECTED);
|
|
|
|
aResult.Truncate(aResult.Length() - 1);
|
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2001-09-20 05:32:16 +04:00
|
|
|
//----------------------------------------------------------------------------
|
|
|
|
// nsResProtocolHandler::nsISupports
|
|
|
|
//----------------------------------------------------------------------------
|
|
|
|
|
2015-07-17 01:50:07 +03:00
|
|
|
NS_IMPL_QUERY_INTERFACE(nsResProtocolHandler, nsIResProtocolHandler,
|
|
|
|
nsISubstitutingProtocolHandler, nsIProtocolHandler,
|
|
|
|
nsISupportsWeakReference)
|
|
|
|
NS_IMPL_ADDREF_INHERITED(nsResProtocolHandler, SubstitutingProtocolHandler)
|
|
|
|
NS_IMPL_RELEASE_INHERITED(nsResProtocolHandler, SubstitutingProtocolHandler)
|
2008-10-01 09:15:58 +04:00
|
|
|
|
2017-06-08 12:44:09 +03:00
|
|
|
NS_IMETHODIMP
|
|
|
|
nsResProtocolHandler::AllowContentToAccess(nsIURI* aURI, bool* aResult) {
|
|
|
|
*aResult = false;
|
|
|
|
|
|
|
|
nsAutoCString host;
|
|
|
|
nsresult rv = aURI->GetAsciiHost(host);
|
|
|
|
NS_ENSURE_SUCCESS(rv, rv);
|
|
|
|
|
|
|
|
uint32_t flags;
|
|
|
|
rv = GetSubstitutionFlags(host, &flags);
|
|
|
|
NS_ENSURE_SUCCESS(rv, rv);
|
|
|
|
|
|
|
|
*aResult = flags & nsISubstitutingProtocolHandler::ALLOW_CONTENT_ACCESS;
|
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
nsresult nsResProtocolHandler::GetSubstitutionInternal(const nsACString& aRoot,
|
|
|
|
nsIURI** aResult,
|
|
|
|
uint32_t* aFlags) {
|
Bug 1225384 - Change how the default resource "host names" are handled. r=michal
The meaning of resource:///, resource://app/ and resource://gre/ needs to
remain constant. Unfortunately, the model of the resource protocol handler
is that it is possible to set substitutions that change their meaning.
So, we forbid setting overwriting the substitutions for those three
special "host names".
Unfortunately, with e10s, the full list of substitutions is also sent to
the content process, which then sets substitutions, making it harder to
know in which cases SetSubstitution is valid for those three "host names"
or not.
So instead of trying to find the right heuristics, use the recently added
SubstitutingProtocolHandler::ResolveSpecialCases API to handle the three
"host names" instead of storing them as "normal" substitutions.
Still actively reject SetSubstitution with the three special "host names"
so as to find issues such as bug 1224000 instead of allowing the chrome
manifest entry and have it silently ignored.
Additionally, make GetSubstitution return the URIs for the three special
"host names" through GetSubstitutionInternal, replacing what was originally
added in bug 257162. Those changes from bug 257162 relied on the
resource:app string being handled by nsXREDirProvider::GetFile, but that was
removed in bug 620931, effectively making that code now in
GetSubstitutionInternal useless.
2015-11-17 11:21:03 +03:00
|
|
|
nsAutoCString uri;
|
2004-09-07 22:59:07 +04:00
|
|
|
|
2017-06-08 12:44:09 +03:00
|
|
|
if (!ResolveSpecialCases(aRoot, NS_LITERAL_CSTRING("/"),
|
|
|
|
NS_LITERAL_CSTRING("/"), uri)) {
|
2004-09-07 22:59:07 +04:00
|
|
|
return NS_ERROR_NOT_AVAILABLE;
|
Bug 1225384 - Change how the default resource "host names" are handled. r=michal
The meaning of resource:///, resource://app/ and resource://gre/ needs to
remain constant. Unfortunately, the model of the resource protocol handler
is that it is possible to set substitutions that change their meaning.
So, we forbid setting overwriting the substitutions for those three
special "host names".
Unfortunately, with e10s, the full list of substitutions is also sent to
the content process, which then sets substitutions, making it harder to
know in which cases SetSubstitution is valid for those three "host names"
or not.
So instead of trying to find the right heuristics, use the recently added
SubstitutingProtocolHandler::ResolveSpecialCases API to handle the three
"host names" instead of storing them as "normal" substitutions.
Still actively reject SetSubstitution with the three special "host names"
so as to find issues such as bug 1224000 instead of allowing the chrome
manifest entry and have it silently ignored.
Additionally, make GetSubstitution return the URIs for the three special
"host names" through GetSubstitutionInternal, replacing what was originally
added in bug 257162. Those changes from bug 257162 relied on the
resource:app string being handled by nsXREDirProvider::GetFile, but that was
removed in bug 620931, effectively making that code now in
GetSubstitutionInternal useless.
2015-11-17 11:21:03 +03:00
|
|
|
}
|
|
|
|
|
Bug 1522137 - Make resource://android return a nsIJARURI. r=snorp,mayhemer,bzbarsky
resource://android URIs always point to a "jar:" URI so it doesn't make sense
that the returned URL object implements nsIFileURL.
This also makes it so extensions can be loaded from a resource://android URI.
Audited all places where we use `nsIJARURI` and check for places where we
assume it looks like `jar:`: the only (!) place where we do that is here:
https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/dom/xhr/XMLHttpRequestMainThread.cpp#1852
Where we have special handling for `jar:` URIs. It looks like we would have
less special handling for such a request to a `resource://android` and it could
be fixed by just checking for the interface instead, but that's what's already
happening today so it should work. That code is never reached for
`resource://android` URIs as `mIsMappedArrayBuffer` is false for those URIs
(see #2822). And the code is consistent in checking for the scheme instead of
the interface (the other check is here:
https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/dom/xhr/XMLHttpRequestMainThread.cpp#2822)
Audited all places where we do `EqualsLiteral("jar")`:
https://searchfox.org/mozilla-central/search?q=.EqualsLiteral%28%22jar%22%29&path=
`SubstituteRemoteChannel`: looks interesting, but uses
`nsISubstitutingProtocolHandler::ResolveURI` to first get the real URI (which
is a `jar:`) so it works for our case.
https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/netwerk/protocol/res/ExtensionProtocolHandler.cpp#414
`SubstitutingProtocolHandler.cpp`
This case is explicitly fixed by this change, making it account for both
`"jar"` and `"resource"`.
https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/netwerk/protocol/res/SubstitutingProtocolHandler.cpp#299
`ReadSourceFromFileName`: this also looks interesting, but uses the channel to
get the URI which returns the real `"jar"` URI and not the mapped `"resource"`.
https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/js/xpconnect/src/XPCJSRuntime.cpp#2837
`nsStringBundle.cpp`
Accounts for both `"jar"` and `"resource"`, so it should work the same.
https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/intl/strres/nsStringBundle.cpp#437
Audited all places where we use `nsINestedURI` to make sure they would work for
a `nsIJARURI` which does not implement `nsINestedURI`.
`BrowserContentHandler.jsm`
Uses `nsINestedURI` to figure out if a URI is local or not and then it checks
whether it's a `"file"`, `"resource"` or `"chrome"` URI, for a `nsIJARURI &
nsINestedURI` it would return a `"file"` which passes the test, for a
`nsIJARURI` alone it would return `"resource"` which is also considered local
by this code, so the result wouldn't change.
https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/browser/components/BrowserContentHandler.jsm#395-399
`nsScriptSecurityManager.cpp`
`GetOriginFromURI`: This is the reason why `SubstitutingJARURI` doesn't
implement `nsINestedURI`, the origin is computed starting from the innermost
URI, which in our case would be a file. The behavior in our case is that the
origin from a `resource://android` URI behaves like other `resource://` URIs,
which is what we expect.
https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/caps/nsScriptSecurityManager.cpp#169
`CheckLoadURIWithPrincipal`: for `nsIJARURI & nsINestedURI` this code will only
allow pages from the same jar to be in the same origin (which is correct), for
`nsIJARURI` this code is unreachable and it would allow every
`resource://android` to load every other `resource://android` URI (which is
essentially the same thing).
https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/caps/nsScriptSecurityManager.cpp#874-876
`nsDocShell.cpp`
`DisplayLoadError`: Just looping through the nested URI chain to build an error
message, no concerns here (it would just ignore the `jar:` part, which is
fine).
https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/docshell/base/nsDocShell.cpp#3986
`DoURILoad`: Looking for `view-source`, no concerns for `resource://android`.
https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/docshell/base/nsDocShell.cpp#9645
`nsObjectLoadingContent.cpp`
Also looking for `view-source`, no concerns.
https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/dom/base/nsObjectLoadingContent.cpp#2004
`nsIconURI.cpp`/`nsIconURI.h`
Exposing `nsINestedURI`. No concerns.
https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/image/decoders/icon/nsIconURI.cpp#58
`nsJARURI.cpp`/`nsJARURI.h`
Exposing `nsINestedURI`, the subject of this audit.
https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/modules/libjar/nsJARURI.cpp#45
`nsIOService.cpp`
`URIChainHasFlags`: This code looks at the chain of nested URIs to figure out
if the chain of protocols has a certain flags. for `nsIJARURI & nsINestedURI`
it would look at both `jar:` and `file:` protocols, while in `nsIJARURI` it
would only look at the `resource:` protocol, which is our intention, since we
want this URI to be treated like a `resource:` URI and nothing else. Note the
`resource:` URI is always local (enforced by `NewURI`), so this should be ok.
https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/netwerk/base/nsIOService.cpp#1494
`nsNetUtil.cpp`/`nsNetUtil.h`
Implementation of `NS_ImplGetInnermostURI`, which wouldn't work for `nsIJARURI`
alone, as expected.
https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/netwerk/base/nsNetUtil.h#704
`nsSimpleNestedURI.cpp`/`nsSimpleNestedURI.h`
Implementing `nsINestedURI` for `nsSimpleNestedURI`, no concerns.
https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/netwerk/base/nsSimpleNestedURI.cpp#19
`nsViewSourceHandler.cpp`
Looking at `view-source` inner URI to get the flags, no concerns.
https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/netwerk/protocol/viewsource/nsViewSourceHandler.cpp#49
`nsHtml5StreamParser.cpp`/`nsHtml5TreeOpExecutor.cpp`
More `view-source` handling code. No concerns.
https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/parser/html/nsHtml5StreamParser.cpp#310
https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/parser/html/nsHtml5TreeOpExecutor.cpp#884
`DownloadPlatform.cpp`
`IsURLPossiblyFromWeb`: This line is unreachable as the method would return
true because resource has `URI_IS_UI_RESOURCE`.
https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/toolkit/components/downloads/DownloadPlatform.cpp#314
`getAnonymizedPath`: This code looks a little scary, and it's the first one
that seems to conflate the fact that `jar: == nsINestedURI`.
On the android case (line 2130) this code manually replaces the
`resource://android` URI with a `jar:` URI, so it wouldn't matter whether
`resource://android` implements `nsINestedURI` or not.
Actually this code could be a lot easier by using
`nsISubstitutingURL::resolveURI`, maybe I should open a bug.
https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/toolkit/components/search/SearchService.jsm#2148
`getRemoteTypeForURIObject`: This also looks interesting. The switch at line
157 would go straight to line 218 for `resource:` URIs (irrespective of
`nsINestedURI`) and then for `nsINestedURI` we would look at the `jar:` URI
(and eventually the `file:` URI). While for not `nsINestedURI` we would call
straight to `validatedWebRemoteType`. This might return `WEB_REMOTE_TYPE`
instead of `FILE_REMOTE_TYPE`, but since it's already happening it should be ok
(`resource://android` maps _today_ to a `jar:` file that return
`WEB_RETURN_TYPE`)
https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/toolkit/modules/E10SUtils.jsm#150
`getURIHost`:
This is another piece of code that benefits from not implementing
`nsINestedURI` as the host would be correctly `"android"` instead of the apk
path.
https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/toolkit/mozapps/downloads/DownloadUtils.jsm#390
`initDialog`:
Download dialog would show the `resource://android` URI instead of the actual
`jar:` URI, kind of expected.
https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/toolkit/mozapps/downloads/HelperAppDlg.jsm#423
There are no places in the codebase where we do `== "jar"`. Looks like I've
already looked at all hits for "jar" too.
Checked for `"jar:` too and It looks like they are all from code that tries to
build a `jar:` URI manually which is fine for this change.
Audited all `schemeIs("jar")` occurrences:
https://searchfox.org/mozilla-central/search?q=schemeIs(%22jar%22)&path=
`browser-identity.js`
Uses the channel URI which is always resolved to `jar:`, so that works
regardless. See also:
https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/netwerk/protocol/res/SubstitutingProtocolHandler.cpp#229
https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/browser/base/content/browser-siteIdentity.js#812
`tabbrowser.js`
Only for `scheme == "about"` URIs.
https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/browser/base/content/tabbrowser.js#789
`HelperAppDialog.js`
Treats "jar:" and "resource" the same way.
https://searchfox.org/mozilla-central/rev/dc0adc07db3df9431a0876156f50c65d580010cb/mobile/android/components/HelperAppDialog.js#63
`WebNavigationContent.js`
This code checks if the scheme is "jar" and if the original URI is "resource"
it will use that instead, so in our case it will use the "resource" URI either
way.
https://searchfox.org/mozilla-central/rev/dc0adc07db3df9431a0876156f50c65d580010cb/toolkit/modules/addons/WebNavigationContent.js#158
Depends on D18740
Differential Revision: https://phabricator.services.mozilla.com/D16913
--HG--
extra : moz-landing-system : lando
2019-02-25 18:38:33 +03:00
|
|
|
if (aRoot.Equals(kAndroid)) {
|
|
|
|
*aFlags = nsISubstitutingProtocolHandler::RESOLVE_JAR_URI;
|
|
|
|
} else {
|
|
|
|
*aFlags = 0; // No content access.
|
|
|
|
}
|
2017-06-08 12:44:09 +03:00
|
|
|
return NS_NewURI(aResult, uri);
|
Bug 1225384 - Change how the default resource "host names" are handled. r=michal
The meaning of resource:///, resource://app/ and resource://gre/ needs to
remain constant. Unfortunately, the model of the resource protocol handler
is that it is possible to set substitutions that change their meaning.
So, we forbid setting overwriting the substitutions for those three
special "host names".
Unfortunately, with e10s, the full list of substitutions is also sent to
the content process, which then sets substitutions, making it harder to
know in which cases SetSubstitution is valid for those three "host names"
or not.
So instead of trying to find the right heuristics, use the recently added
SubstitutingProtocolHandler::ResolveSpecialCases API to handle the three
"host names" instead of storing them as "normal" substitutions.
Still actively reject SetSubstitution with the three special "host names"
so as to find issues such as bug 1224000 instead of allowing the chrome
manifest entry and have it silently ignored.
Additionally, make GetSubstitution return the URIs for the three special
"host names" through GetSubstitutionInternal, replacing what was originally
added in bug 257162. Those changes from bug 257162 relied on the
resource:app string being handled by nsXREDirProvider::GetFile, but that was
removed in bug 620931, effectively making that code now in
GetSubstitutionInternal useless.
2015-11-17 11:21:03 +03:00
|
|
|
}
|
2004-09-07 22:59:07 +04:00
|
|
|
|
Bug 1225384 - Change how the default resource "host names" are handled. r=michal
The meaning of resource:///, resource://app/ and resource://gre/ needs to
remain constant. Unfortunately, the model of the resource protocol handler
is that it is possible to set substitutions that change their meaning.
So, we forbid setting overwriting the substitutions for those three
special "host names".
Unfortunately, with e10s, the full list of substitutions is also sent to
the content process, which then sets substitutions, making it harder to
know in which cases SetSubstitution is valid for those three "host names"
or not.
So instead of trying to find the right heuristics, use the recently added
SubstitutingProtocolHandler::ResolveSpecialCases API to handle the three
"host names" instead of storing them as "normal" substitutions.
Still actively reject SetSubstitution with the three special "host names"
so as to find issues such as bug 1224000 instead of allowing the chrome
manifest entry and have it silently ignored.
Additionally, make GetSubstitution return the URIs for the three special
"host names" through GetSubstitutionInternal, replacing what was originally
added in bug 257162. Those changes from bug 257162 relied on the
resource:app string being handled by nsXREDirProvider::GetFile, but that was
removed in bug 620931, effectively making that code now in
GetSubstitutionInternal useless.
2015-11-17 11:21:03 +03:00
|
|
|
bool nsResProtocolHandler::ResolveSpecialCases(const nsACString& aHost,
|
|
|
|
const nsACString& aPath,
|
2016-07-12 23:55:14 +03:00
|
|
|
const nsACString& aPathname,
|
Bug 1225384 - Change how the default resource "host names" are handled. r=michal
The meaning of resource:///, resource://app/ and resource://gre/ needs to
remain constant. Unfortunately, the model of the resource protocol handler
is that it is possible to set substitutions that change their meaning.
So, we forbid setting overwriting the substitutions for those three
special "host names".
Unfortunately, with e10s, the full list of substitutions is also sent to
the content process, which then sets substitutions, making it harder to
know in which cases SetSubstitution is valid for those three "host names"
or not.
So instead of trying to find the right heuristics, use the recently added
SubstitutingProtocolHandler::ResolveSpecialCases API to handle the three
"host names" instead of storing them as "normal" substitutions.
Still actively reject SetSubstitution with the three special "host names"
so as to find issues such as bug 1224000 instead of allowing the chrome
manifest entry and have it silently ignored.
Additionally, make GetSubstitution return the URIs for the three special
"host names" through GetSubstitutionInternal, replacing what was originally
added in bug 257162. Those changes from bug 257162 relied on the
resource:app string being handled by nsXREDirProvider::GetFile, but that was
removed in bug 620931, effectively making that code now in
GetSubstitutionInternal useless.
2015-11-17 11:21:03 +03:00
|
|
|
nsACString& aResult) {
|
2017-09-06 11:13:45 +03:00
|
|
|
if (aHost.EqualsLiteral("") || aHost.EqualsLiteral(kAPP)) {
|
Bug 1225384 - Change how the default resource "host names" are handled. r=michal
The meaning of resource:///, resource://app/ and resource://gre/ needs to
remain constant. Unfortunately, the model of the resource protocol handler
is that it is possible to set substitutions that change their meaning.
So, we forbid setting overwriting the substitutions for those three
special "host names".
Unfortunately, with e10s, the full list of substitutions is also sent to
the content process, which then sets substitutions, making it harder to
know in which cases SetSubstitution is valid for those three "host names"
or not.
So instead of trying to find the right heuristics, use the recently added
SubstitutingProtocolHandler::ResolveSpecialCases API to handle the three
"host names" instead of storing them as "normal" substitutions.
Still actively reject SetSubstitution with the three special "host names"
so as to find issues such as bug 1224000 instead of allowing the chrome
manifest entry and have it silently ignored.
Additionally, make GetSubstitution return the URIs for the three special
"host names" through GetSubstitutionInternal, replacing what was originally
added in bug 257162. Those changes from bug 257162 relied on the
resource:app string being handled by nsXREDirProvider::GetFile, but that was
removed in bug 620931, effectively making that code now in
GetSubstitutionInternal useless.
2015-11-17 11:21:03 +03:00
|
|
|
aResult.Assign(mAppURI);
|
|
|
|
} else if (aHost.Equals(kGRE)) {
|
|
|
|
aResult.Assign(mGREURI);
|
2019-02-25 18:38:21 +03:00
|
|
|
#ifdef ANDROID
|
|
|
|
} else if (aHost.Equals(kAndroid)) {
|
|
|
|
aResult.Assign(mApkURI);
|
|
|
|
#endif
|
Bug 1225384 - Change how the default resource "host names" are handled. r=michal
The meaning of resource:///, resource://app/ and resource://gre/ needs to
remain constant. Unfortunately, the model of the resource protocol handler
is that it is possible to set substitutions that change their meaning.
So, we forbid setting overwriting the substitutions for those three
special "host names".
Unfortunately, with e10s, the full list of substitutions is also sent to
the content process, which then sets substitutions, making it harder to
know in which cases SetSubstitution is valid for those three "host names"
or not.
So instead of trying to find the right heuristics, use the recently added
SubstitutingProtocolHandler::ResolveSpecialCases API to handle the three
"host names" instead of storing them as "normal" substitutions.
Still actively reject SetSubstitution with the three special "host names"
so as to find issues such as bug 1224000 instead of allowing the chrome
manifest entry and have it silently ignored.
Additionally, make GetSubstitution return the URIs for the three special
"host names" through GetSubstitutionInternal, replacing what was originally
added in bug 257162. Those changes from bug 257162 relied on the
resource:app string being handled by nsXREDirProvider::GetFile, but that was
removed in bug 620931, effectively making that code now in
GetSubstitutionInternal useless.
2015-11-17 11:21:03 +03:00
|
|
|
} else {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
aResult.Append(aPath);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
nsresult nsResProtocolHandler::SetSubstitution(const nsACString& aRoot,
|
|
|
|
nsIURI* aBaseURI) {
|
2017-09-06 11:13:45 +03:00
|
|
|
MOZ_ASSERT(!aRoot.EqualsLiteral(""));
|
|
|
|
MOZ_ASSERT(!aRoot.EqualsLiteral(kAPP));
|
|
|
|
MOZ_ASSERT(!aRoot.EqualsLiteral(kGRE));
|
2019-02-25 18:38:21 +03:00
|
|
|
MOZ_ASSERT(!aRoot.EqualsLiteral(kAndroid));
|
Bug 1225384 - Change how the default resource "host names" are handled. r=michal
The meaning of resource:///, resource://app/ and resource://gre/ needs to
remain constant. Unfortunately, the model of the resource protocol handler
is that it is possible to set substitutions that change their meaning.
So, we forbid setting overwriting the substitutions for those three
special "host names".
Unfortunately, with e10s, the full list of substitutions is also sent to
the content process, which then sets substitutions, making it harder to
know in which cases SetSubstitution is valid for those three "host names"
or not.
So instead of trying to find the right heuristics, use the recently added
SubstitutingProtocolHandler::ResolveSpecialCases API to handle the three
"host names" instead of storing them as "normal" substitutions.
Still actively reject SetSubstitution with the three special "host names"
so as to find issues such as bug 1224000 instead of allowing the chrome
manifest entry and have it silently ignored.
Additionally, make GetSubstitution return the URIs for the three special
"host names" through GetSubstitutionInternal, replacing what was originally
added in bug 257162. Those changes from bug 257162 relied on the
resource:app string being handled by nsXREDirProvider::GetFile, but that was
removed in bug 620931, effectively making that code now in
GetSubstitutionInternal useless.
2015-11-17 11:21:03 +03:00
|
|
|
return SubstitutingProtocolHandler::SetSubstitution(aRoot, aBaseURI);
|
1999-11-23 15:13:33 +03:00
|
|
|
}
|
2017-06-08 12:44:09 +03:00
|
|
|
|
|
|
|
nsresult nsResProtocolHandler::SetSubstitutionWithFlags(const nsACString& aRoot,
|
|
|
|
nsIURI* aBaseURI,
|
|
|
|
uint32_t aFlags) {
|
2017-09-06 11:13:45 +03:00
|
|
|
MOZ_ASSERT(!aRoot.EqualsLiteral(""));
|
|
|
|
MOZ_ASSERT(!aRoot.EqualsLiteral(kAPP));
|
|
|
|
MOZ_ASSERT(!aRoot.EqualsLiteral(kGRE));
|
2019-02-25 18:38:21 +03:00
|
|
|
MOZ_ASSERT(!aRoot.EqualsLiteral(kAndroid));
|
2017-06-08 12:44:09 +03:00
|
|
|
return SubstitutingProtocolHandler::SetSubstitutionWithFlags(aRoot, aBaseURI,
|
|
|
|
aFlags);
|
|
|
|
}
|
2019-02-25 18:38:08 +03:00
|
|
|
|
|
|
|
nsresult nsResProtocolHandler::HasSubstitution(const nsACString& aRoot,
|
|
|
|
bool* aResult) {
|
2019-02-25 18:38:21 +03:00
|
|
|
if (aRoot.EqualsLiteral(kAPP) || aRoot.EqualsLiteral(kGRE)
|
|
|
|
#ifdef ANDROID
|
|
|
|
|| aRoot.EqualsLiteral(kAndroid)
|
|
|
|
#endif
|
|
|
|
) {
|
2019-02-25 18:38:08 +03:00
|
|
|
*aResult = true;
|
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
return mozilla::net::SubstitutingProtocolHandler::HasSubstitution(aRoot,
|
|
|
|
aResult);
|
|
|
|
}
|