* calculateNetworkId is now called before sending each ChangeEvent
* mNetworkId is truncated when no IPv4/IPv6 IDs could be computed
Differential Revision: https://phabricator.services.mozilla.com/D35780
--HG--
extra : moz-landing-system : lando
Previously we would throw in nsFtpProtocolHandler::NewURI. Since that doesn't exist anymore, and creating FTP URLs always works, we need to make sure creating the FTP channel doesn't work anymore.
Differential Revision: https://phabricator.services.mozilla.com/D35642
--HG--
extra : moz-landing-system : lando
Change the User-Agent HTTP header and the navigator.userAgent, navigator.platform, and navigator.oscpu APIs to say "Win64" instead "WOW64" (bug 444770) when the user is running 32-bit Firefox on Win64 OS. Software download websites that try to sniff for the user's CPU architecture (so they can serve compatible software) only need to know whether the user has a 32- or 64-bit OS, not whether they are running a 32- or 64-bit Firefox build.
Once upon a time, Mozilla's Plugin Finder Service needed to check whether Firefox was 32- or 64-bit so it could direct the user to a Flash Player plugin compatible with their Firefox build (bug 265536). But these days Adobe's Flash Player installer includes both 32- and 64-bit plugins.
Depends on D35164
Differential Revision: https://phabricator.services.mozilla.com/D35165
--HG--
extra : moz-landing-system : lando
Change the User-Agent HTTP header and the navigator.userAgent, navigator.platform, and navigator.oscpu APIs to say "Linux x86_64" instead "Linux i686 on x86_64" (bug 265536) when the user is running 32-bit Firefox on a 64-bit Unix OS (including Android). Software download websites that try to sniff for the user's CPU architecture (so they can serve compatible software) only need to know whether the user has a 32- or 64-bit OS, not whether they are running a 32- or 64-bit Firefox build.
Once upon a time, Mozilla's Plugin Finder Service needed to check whether Firefox was 32- or 64-bit so it could direct the user to a Flash Player plugin compatible with their Firefox build (bug 265536). But these days Adobe's Flash Player installer includes both 32- and 64-bit plugins.
Differential Revision: https://phabricator.services.mozilla.com/D35164
--HG--
extra : moz-landing-system : lando
Raw pointer to Http2PushedStream is passed to nsHttpChannel and nsHttpTransaction to get it back to a new Http2Stream in the Http2Session. As a result Http2PushedStream's methods can be called on a wrong thread and possibly on already freed object. This patch uses Http2PushedStreamWrapper instead, which takes care about thread safety and checks if the object is still alive.
Differential Revision: https://phabricator.services.mozilla.com/D33511
--HG--
extra : moz-landing-system : lando
This patch adds:
* tests that we restart the TRR connection if it gets abnormally shut down
* a way to terminate the TRR connection when attempting to resolve closeme.com
* makes sure that resolving excluded domains with the DISABLE_TRR flag does
not fail. Before this we would return an error code without checking the
excluded domains first.
Differential Revision: https://phabricator.services.mozilla.com/D35076
--HG--
extra : moz-landing-system : lando
If we find a usable cache entry, the stream is closed and release in CachePushCheckCallback::OnCacheEntryCheck(). This patch converts raw pointer to a weak pointer, so we can simply check if the object still exists after AsyncOpenURI() finishes.
Differential Revision: https://phabricator.services.mozilla.com/D33945
--HG--
extra : moz-landing-system : lando
This patche changes only security/manager/ssl/SSLServerCertVerification.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D28741
--HG--
extra : moz-landing-system : lando
Origin: honors ReferrerPolicy: so we should honor defaultPolicy set by user
Differential Revision: https://phabricator.services.mozilla.com/D34979
--HG--
extra : moz-landing-system : lando
The parsing code uses filename without checking its presence. This patch ensures that the filename contains at least one non white space character.
Differential Revision: https://phabricator.services.mozilla.com/D34485
--HG--
extra : moz-landing-system : lando
Changes:
- move xpcshell from macosx1010 to macosx1014
- updated regex for macosx1014 xpcshell to run on 2 chunks for all variants (for now)
Differential Revision: https://phabricator.services.mozilla.com/D34561
--HG--
extra : moz-landing-system : lando
To run task_for_pid() on child processes, we need the child task port for
security reasons. This port can be obtained via a Mach IPC exchange.
This is what GeckoChildProcessHost::GetChildTask() provides, so we use it
in cocoa's version of GetProcInfo()
Differential Revision: https://phabricator.services.mozilla.com/D25927
--HG--
extra : moz-landing-system : lando
This ensures that links in about:license to about:rights and about:buildconfig actually work.
Differential Revision: https://phabricator.services.mozilla.com/D34136
--HG--
extra : moz-landing-system : lando
To run task_for_pid() on child processes, we need the child task port for
security reasons. This port can be obtained via a Mach IPC exchange.
This is what GeckoChildProcessHost::GetChildTask() provides, so we use it
in cocoa's version of GetProcInfo()
Differential Revision: https://phabricator.services.mozilla.com/D25927
--HG--
extra : moz-landing-system : lando
For a popup, the principal will be that of the opener, so we can't use that to
determine if the window is about:blank.
Differential Revision: https://phabricator.services.mozilla.com/D33249
--HG--
extra : moz-landing-system : lando
Since the RESOLVE_JAR_URI flag is not used for moz-extension, ResolveJARURI
would never get called in ExtensionProtocolHandler, so it's OK to consider
it threadsafe.
Differential Revision: https://phabricator.services.mozilla.com/D33253
--HG--
extra : moz-landing-system : lando
The problem with CaptiveDetect was that it uses an XMLHttpRequest, and
apparently xhr.status is 0 for failed requests, which here includes cert
errors, redirect loops, etc.
Getting the XHR to not follow redirects was tricky, so a hacky fix was to
set nsIHttpChannel.redirectionLimit = 0;
For any redirect the XHR would now fail with NS_ERROR_REDIRECT_LOOP, which
we need to handle separately.
I also included tests for:
* redirect to https with invalid cert
* redirect to same URL causing redirect loop
* redirect to different URL with different content
* redirect to different URL with canonical content
All of these cases should be detected as locked captive portals.
Differential Revision: https://phabricator.services.mozilla.com/D33706
--HG--
extra : moz-landing-system : lando
The vast majority of the virtual methods which were used on ProtocolState were
actually methods which only had meaningful implementations on the toplevel
protocol. This patch adds a new field to IProtocol holding a direct pointer to
the protocol's `IToplevelProtocol`, and the methods formerly implemented with
ProtocolState now directly call the corresponding method on IToplevelProtocol.
IToplevelProtocol then shadows these methods with the toplevel protocol
implementation, meaning that the right code is run in the right places.
In addition, some state was maintained for protocols inside of the separate
ProtocolState allocation, and this patch moves that state back into the actor
itself.
Differential Revision: https://phabricator.services.mozilla.com/D32044
--HG--
extra : moz-landing-system : lando
Also, in many place, we use document uri as referrer. It is not right
for the case srdoc iframe. We should use the last non-srdoc parent
document's uri
Differential Revision: https://phabricator.services.mozilla.com/D30191
--HG--
rename : testing/web-platform/tests/referrer-policy/generic/iframe-inheritance.html => testing/web-platform/tests/referrer-policy/generic/inheritance/iframe-inheritance-data.html
rename : testing/web-platform/tests/referrer-policy/generic/iframe-inheritance.html => testing/web-platform/tests/referrer-policy/generic/inheritance/iframe-inheritance-srcdoc.html
extra : moz-landing-system : lando
NS_HTTP_ONPUSH_LISTENER capability is set in nsHttpChannel::SetupTransaction when notification callbacks implement nsIHttpPushListener, but nsHttpChannel::OnPush event is initiated on socket thread in Http2PushedStream::TryOnPush and the channel can be closed and listeners released before nsHttpChannel::OnPush is called on the main thread.
Differential Revision: https://phabricator.services.mozilla.com/D33776
--HG--
extra : moz-landing-system : lando
This patch calls NetworkConnectivityService::GetSingleton() on the main thread
and keeps a ref to the service until shutdown.
Even though calling ncs->GetIPv6() off-main-thread is technically a data-race
in practice that's OK because only the simple decision whether to send
AAAA requests is made based on that value, which in itself is an optimization.
I filed bug 1556967 for making the connectivity service thread safe.
Differential Revision: https://phabricator.services.mozilla.com/D33765
--HG--
extra : moz-landing-system : lando
Normally, this method will return the entire in string if it has a scheme.
However, mParser->ParseURL may fail, leading to the scheme to be cleared,
and the result will be the same HTTP URL with the input appended to the
path. This triggers the assertion in NS_NewURI that the scheme should not
change.
As a fix, we bail out of nsStandardURL::Resolve() if the parsed scheme of
the input is different than the base URIs current scheme. This condition
is necessary, because we still need to support a deprecated form of relative
URLs like http:file or http:/path/file
Differential Revision: https://phabricator.services.mozilla.com/D33003
--HG--
extra : moz-landing-system : lando
This way we preserve the behaviour of getaddrinfo, where both A and AAAA
responses come back at the same time.
Without this Firefox will always be biased, as the first request will usually
be resolved first. So if we requested IPv4 first, we'd mostly be using IPv4.
If we requested IPv6 first, normally we'll wait for the IPv4 response to come
back too, which is functionally equivalent to the new behaviour.
However, if the pref is set network.trr.early-AAAA;true then we'd use the IPv6
response immediately, possibly leading to a failed request if the IPv6
connection fails before we have an IPv4 address to fall back to.
A test for this patch was added in bug 1542561.
Depends on D33476
Differential Revision: https://phabricator.services.mozilla.com/D33477
--HG--
extra : moz-landing-system : lando
This is an optimization. If we detect that the system can't use the IPv6
address, there's no point in making a request for it.
Depends on D33475
Differential Revision: https://phabricator.services.mozilla.com/D33476
--HG--
extra : moz-landing-system : lando
This test uses prefs added in Bug 1518730, but the pref is ignored when it
doesn't exist, so the test is still valid.
Depends on D33471
Differential Revision: https://phabricator.services.mozilla.com/D33473
--HG--
extra : moz-landing-system : lando
Normally, this method will return the entire in string if it has a scheme.
However, mParser->ParseURL may fail, leading to the scheme to be cleared,
and the result will be the same HTTP URL with the input appended to the
path. This triggers the assertion in NS_NewURI that the scheme should not
change.
As a fix, we bail out of nsStandardURL::Resolve() if the parsed scheme of
the input is different than the base URIs current scheme. This condition
is necessary, because we still need to support a deprecated form of relative
URLs like http:file or http:/path/file
Differential Revision: https://phabricator.services.mozilla.com/D33003
--HG--
extra : moz-landing-system : lando
It is no longer necesssary for individual actors to do this book-keeping
manually.
Differential Revision: https://phabricator.services.mozilla.com/D33159
--HG--
extra : moz-landing-system : lando
We do this because we will be introducing more privileged content processes
and we want to be able to distinguish them.
Differential Revision: https://phabricator.services.mozilla.com/D30274
--HG--
rename : browser/base/content/test/tabs/browser_new_tab_in_privileged_process_pref.js => browser/base/content/test/tabs/browser_new_tab_in_privilegedabout_process_pref.js
extra : moz-landing-system : lando
We do this because we will be introducing more privileged content processes
and we want to be able to distinguish them.
Differential Revision: https://phabricator.services.mozilla.com/D30274
--HG--
rename : browser/base/content/test/tabs/browser_new_tab_in_privileged_process_pref.js => browser/base/content/test/tabs/browser_new_tab_in_privilegedabout_process_pref.js
extra : moz-landing-system : lando
The only protocol that can't be created off the main thread at the moment is
moz-extension, and that can be handled at a later time.
Differential Revision: https://phabricator.services.mozilla.com/D30713
--HG--
extra : moz-landing-system : lando
This is needed to pass a web-platform-test. Since unknown protocols use
nsSimpleURI and nsSimpleURI::GetHost returns an error code, that will fail.
Instead, we instantiate an nsStandardURL for the ssh scheme.
Once we change nsSimpleURI to be backed by MozURL we can probably remove this.
Differential Revision: https://phabricator.services.mozilla.com/D30707
--HG--
extra : moz-landing-system : lando
Before, we'd try to create a URI using the GIO protocol handler, and if that
succeeded, we'd return the protocol handler.
Now we can't return it if NS_NewURI succeeds, because NS_NewURI doesn't check
the protocol handler anymore. So instead we just instantiate the handler,
check if the scheme is supported, and if so return it.
Differential Revision: https://phabricator.services.mozilla.com/D30706
--HG--
extra : moz-landing-system : lando
nsSimpleURI doesn't really have the concept of a relative URI.
Since unknown protocol schemes will ultimately fall back to using nsSimpleURI,
we need to make sure that resolving a URI with certain base still works as
before, when those URIs were nsStandardURLs, created by the protocol handlers.
To achieve this we check to see if the "relative path" has a scheme. If it
does, we just return it, to be parsed by NS_NewURI. Otherwise, we use
MozURL (based on rust-url) to figure out the correct relative URL we should
return. This by itself manages to fix several failing web-platform tests.
Differential Revision: https://phabricator.services.mozilla.com/D30705
--HG--
extra : moz-landing-system : lando
* Add main thread assertions for "resource" and "moz-extension" protocols
* Use ::GetSingleton() for resource and moz-extension protocol handlers
Differential Revision: https://phabricator.services.mozilla.com/D30698
--HG--
extra : moz-landing-system : lando
This way all of the nsIURI creation will go through NS_NewURIOnAnyThread.
NS_NewURIOnAnyThread will be renamed to NS_NewURI in the final patch.
Differential Revision: https://phabricator.services.mozilla.com/D30696
--HG--
extra : moz-landing-system : lando
These URL types need both specific applications to be installed on Linux, and for the pref to list them as supported.
We do these checks in nsGIOProtocolHandler::NewChannel instead of performing them when creating the URLs.
Differential Revision: https://phabricator.services.mozilla.com/D30695
--HG--
extra : moz-landing-system : lando
This patch splits ReadFromCache in two - by adding ContinueReadFromCache.
ContinueReadFromCache is called asycly when a cross-process-redirect is
complete.
Sometimes, the channel will be cancelled before the cross-process-redirect
is complete, such as in:
testing/firefox-ui/tests/functional/safebrowsing/test_notification.py
In that case we must make sure to call HandleAsyncAbort if the listener's
onStart/StopRequest callbacks haven't been called.
Differential Revision: https://phabricator.services.mozilla.com/D31226
--HG--
extra : moz-landing-system : lando
According to the spec, we should ignore the response body for the HEAD and CONNECT requests.
Differential Revision: https://phabricator.services.mozilla.com/D28678
--HG--
extra : moz-landing-system : lando
This API abstracts away the details of the decision on what context should be
partitioned away from the consumers and centralizes the decision making into
the same location in the code base.
Differential Revision: https://phabricator.services.mozilla.com/D29742
--HG--
extra : moz-landing-system : lando
This new code designates our new cookie policy for blocking cookies and
storage access from third-party trackers and partitioning the cookie jar
of the rest of third-party resources.
Differential Revision: https://phabricator.services.mozilla.com/D29736
--HG--
extra : moz-landing-system : lando
