Previously we had no way from excluding just one channel from TRR mode3.
The solution was to add the captive portal domain to the exclusion list.
Now the captive portal channel is marked with nsIRequest.DISABLE_TRR_MODE so
the exclusion is not necessary anymore.
Differential Revision: https://phabricator.services.mozilla.com/D48820
--HG--
extra : moz-landing-system : lando
* Makes it possible to selectively enable TRR for pbmode/container/window/etc
Differential Revision: https://phabricator.services.mozilla.com/D48363
--HG--
extra : moz-landing-system : lando
The forced garbage collection has been added a decade ago for a test that
exhibited a memory increase over time in Firefox. Now that the test is no
longer present in the tree, and the garbage collector got a lot of improvements
over the last years, there is no compelling reason to keep the call to
"forceGC()" in the closing handler of httpd.js.
Differential Revision: https://phabricator.services.mozilla.com/D58550
--HG--
extra : moz-landing-system : lando
Note that this also implicitly adds support for the view-source+srcdoc configuration, and setting of the BaseURI, which were both in the nsDocShell version but not the others.
Differential Revision: https://phabricator.services.mozilla.com/D57887
--HG--
extra : moz-landing-system : lando
Note that this also implicitly adds support for the view-source+srcdoc configuration, and setting of the BaseURI, which were both in the nsDocShell version but not the others.
Differential Revision: https://phabricator.services.mozilla.com/D57887
--HG--
extra : moz-landing-system : lando
On windows 10-64 asan, we get a failure on the network io test that
checks the sqlite DB is touched. According to the logs, this failure
happens because when the test occurs the write happens in the wal
file. Adapted the test to also check for that location.
Differential Revision: https://phabricator.services.mozilla.com/D58908
--HG--
extra : moz-landing-system : lando
We set a `securityObserver` in `onSocketAccepted` on the main thread to observe `onHandshakeDone`, which might be too late since handshake could complete off main thread. Therefore, when we set `securityObserver` after handshake is completed, call `onHandshakeDone`.
Differential Revision: https://phabricator.services.mozilla.com/D56483
--HG--
extra : moz-landing-system : lando
This is something less hacky to the best of my knowledge. Both passing preferable proxy table and letting system setting handle `ws`/`wss` touch the code of all platforms, which is more fragile.
Differential Revision: https://phabricator.services.mozilla.com/D57176
--HG--
extra : moz-landing-system : lando
This changeset is a simple find and replace of `MOZ_FALLTHROUGH` and `[[fallthrough]]`.
Unfortunately, the MOZ_FALLTHROUGH_ASSERT macro (to assert on case fallthrough in debug builds) is still necessary after switching from [[clang::fallthrough]] to [[fallthrough]] because:
* MOZ_ASSERT(false) followed by [[fallthrough]] triggers a -Wunreachable-code warning in DEBUG builds
* but MOZ_ASSERT(false) without [[fallthrough]] triggers a -Wimplicit-fallthrough warning in NDEBUG builds.
Differential Revision: https://phabricator.services.mozilla.com/D56440
--HG--
extra : moz-landing-system : lando
It turns out we can send messages over PHttpBackgroundChannel before OnStartRequest, in the case where we have content process serviceworkers generating a synthetic response.
This triggers diversion without sending OnStartRequest. We can remove this code again when we remove diversion.
Differential Revision: https://phabricator.services.mozilla.com/D57383
--HG--
extra : moz-landing-system : lando
It turns out we can send messages over PHttpBackgroundChannel before OnStartRequest, in the case where we have content process serviceworkers generating a synthetic response.
This triggers diversion without sending OnStartRequest. We can remove this code again when we remove diversion.
Differential Revision: https://phabricator.services.mozilla.com/D57383
--HG--
extra : moz-landing-system : lando
This stops the originating docshell from showing as loading while a download is in progress, and prevents it from cancelling the download if it tries to navigate again.
Differential Revision: https://phabricator.services.mozilla.com/D57673
--HG--
extra : moz-landing-system : lando
Previously, GetCancelled() would have return true should the channel's status was an error.
Doing Cancel(NS_OK) for example, would have made a follow-up call to GetCancelled() return false. However, we can assert that such a call would have been a bug.
Following this change GetCancelled() will only return true if Cancel() was explicitly called.
Differential Revision: https://phabricator.services.mozilla.com/D55401
--HG--
extra : moz-landing-system : lando
There is no functional change with this commit. The default implementation for GetCanceled() is still to check if the status code is a failure.
However, it can be argued that as you had to call Cancel() on the nsIChannel, having to check the nsIHttpChannelInternal interface to determine if you had been canceled in the past was rather a non obvious path.
It makes more sense to check the nsIChannel interface to determine if it's been canceled already and this allows for finer granularity if needed in the future.
Differential Revision: https://phabricator.services.mozilla.com/D55268
--HG--
extra : moz-landing-system : lando
Granted origins cause a third-party tracker browsing context to not get
full first-party storage access after successfully calling the storage
access API or a heuristic granting ephemeral access.
For example, after https://tracker.example calls the storage access API
successfully in the third-party context, they embed
https://other-tracker.example, and that load fails because of ETP
restrictions. Here what happens is that https://other-tracker.example
is mistakenly considered the granted origin, and because such a
permission doesn't exist, access is denied.
Differential Revision: https://phabricator.services.mozilla.com/D57493
--HG--
extra : moz-landing-system : lando
Granted origins cause a third-party tracker browsing context to not get
full first-party storage access after successfully calling the storage
access API or a heuristic granting ephemeral access.
For example, after https://tracker.example calls the storage access API
successfully in the third-party context, they embed
https://other-tracker.example, and that load fails because of ETP
restrictions. Here what happens is that https://other-tracker.example
is mistakenly considered the granted origin, and because such a
permission doesn't exist, access is denied.
Differential Revision: https://phabricator.services.mozilla.com/D57493
--HG--
extra : moz-landing-system : lando
Granted origins cause a third-party tracker browsing context to not get
full first-party storage access after successfully calling the storage
access API or a heuristic granting ephemeral access.
For example, after https://tracker.example calls the storage access API
successfully in the third-party context, they embed
https://other-tracker.example, and that load fails because of ETP
restrictions. Here what happens is that https://other-tracker.example
is mistakenly considered the granted origin, and because such a
permission doesn't exist, access is denied.
Differential Revision: https://phabricator.services.mozilla.com/D57493
--HG--
extra : moz-landing-system : lando
Previously, GetCancelled() would have return true should the channel's status was an error.
Doing Cancel(NS_OK) for example, would have made a follow-up call to GetCancelled() return false. However, we can assert that such a call would have been a bug.
Following this change GetCancelled() will only return true if Cancel() was explicitly called.
Differential Revision: https://phabricator.services.mozilla.com/D55401
--HG--
extra : moz-landing-system : lando
There is no functional change with this commit. The default implementation for GetCanceled() is still to check if the status code is a failure.
However, it can be argued that as you had to call Cancel() on the nsIChannel, having to check the nsIHttpChannelInternal interface to determine if you had been canceled in the past was rather a non obvious path.
It makes more sense to check the nsIChannel interface to determine if it's been canceled already and this allows for finer granularity if needed in the future.
Differential Revision: https://phabricator.services.mozilla.com/D55268
--HG--
extra : moz-landing-system : lando
We don't want to run stream conversion in the parent (since a lot of them require access to the document), so this instead adds a way to find out what their output type will be.
Differential Revision: https://phabricator.services.mozilla.com/D56134
--HG--
extra : moz-landing-system : lando
We don't want to run stream conversion in the parent (since a lot of them require access to the document), so this instead adds a way to find out what their output type will be.
Differential Revision: https://phabricator.services.mozilla.com/D56134
--HG--
extra : moz-landing-system : lando
`nsAuthSSPI` makes a call to `DeprecatedSyncResolve` that normally issues a DNS
request and blocks until that completes. Apart from being a problem in general
this is an issue when using TRR, because the HTTPS channel to the DoH server
uses the main thread. When `DeprecatedSyncResolve` gets called on the main
thread it then blocks the thread, and since the TRR request never has the
chance to complete (even the TRR cancellation when the timer expires is
processed on the main thread) the result is a deadlock.
This structural problem should be fixed, but until that happens we should
set the `RESOLVE_DISABLE_TRR` flag when calling `ResolveHost` from
`nsDNSService::DeprecatedSyncResolve`
Differential Revision: https://phabricator.services.mozilla.com/D57214
--HG--
extra : moz-landing-system : lando
It is not quite clear to me if GetBrowsingContext can ever be null that is why I opened Bug 1604040.
Differential Revision: https://phabricator.services.mozilla.com/D57247
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
Bug 1597683, added support for setting the DNS suffix list via "Advanced TCP/IP Settings". The changes performed in "Advanced TCP/IP Settings" reflect inside the `Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters` registry key.
However, when setting the Local Group Policy for DNS Suffixes via gpedit, the registry key that gets modified is `Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient`
Note: the setting in gpedit can be found at Computer Configuration > Administrative Templates > Network > DNS Client > DNS suffix search list
This patch first checks for the Local Group Policy registry key, and if not found it checks the one that gets set by the Advanced TCP/IP Settings window.
Differential Revision: https://phabricator.services.mozilla.com/D56344
--HG--
extra : moz-landing-system : lando
CheckMayLoadAndReport takes a window ID. This allows us to report
errors from it to the web console as needed. Most consumers know statically
whether they want reporting or not, so there's no reason to force the ones that
don't to provide window ids.
Differential Revision: https://phabricator.services.mozilla.com/D56388
--HG--
extra : moz-landing-system : lando
This patch makes the matched info also set into the channels in the
parent process. This info is neeced for the ContentBlocking telemetry
and GeckoView also relies on it.
Differential Revision: https://phabricator.services.mozilla.com/D56748
--HG--
extra : moz-landing-system : lando
We make the OnContentBlockingEvent to be notified in the parent procees
for UrlClassifierCommon. There are two place would trigger this,
UrlClassifierCommon::SetBlockedContent and
UrlClassifierCommon::AnnotateChannel. But we still send to the child
process to notify the content blocking since we need to update the log
in the content process in this stage.
Differential Revision: https://phabricator.services.mozilla.com/D55647
--HG--
extra : moz-landing-system : lando
CheckMayLoadAndReport takes a window ID. This allows us to report
errors from it to the web console as needed. Most consumers know statically
whether they want reporting or not, so there's no reason to force the ones that
don't to provide window ids.
Differential Revision: https://phabricator.services.mozilla.com/D56388
--HG--
extra : moz-landing-system : lando
This patch adds DefaultURI which wraps MozURL which in turn forwards calls
to rust-url.
For the moment the added network.url.useDefaultURI is set to false by default.
The plan is to make this the default implementation for unknown URI types.
Differential Revision: https://phabricator.services.mozilla.com/D54748
--HG--
extra : moz-landing-system : lando
The idea of this patch is to try to not use oberver mechanism as possible. To
achieve that, it introduces deleteByOriginAttributes() to cleaners. Different
from other methods, it would only be executed if it's implemented from a
cleaner.
It doesn't remove oberver mechanism entirely since some cleaners are still using
that for other deleteByXXX() functions. So, it only applies removing stuff to
PushService, QuotaManagerService, ServiceWorkerManager, nsPermissionManager,
nsApplicationCacheService, and nsCookieService.
Since the original issue is related to QuotaManagerService, it adds xpcshell
test under the dom/quota/test/unit/ to ensure the behavior won't be changed
accidentally in the future.
Differential Revision: https://phabricator.services.mozilla.com/D33758
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
* Initializes mHasCrossOriginOpenerPolicyMismatch = 0
* Moves ProcessCrossOriginResourcePolicyHeader and ComputeCrossOriginOpenerPolicyMismatch higher in the method, so we call them even when the channel gets cancelled for other reasons.
Differential Revision: https://phabricator.services.mozilla.com/D56228
--HG--
extra : moz-landing-system : lando
This bug is caused by bug 1598676 (Adds NS_DNS_SUFFIX_LIST_UPDATED_TOPIC), and
bug 1598676 (makes CheckAdaptersAddresses be called at startup)
While at startup it's sometimes the case that the NS_NETWORK_LINK_TOPIC and
NS_DNS_SUFFIX_LIST_UPDATED_TOPIC are both called, due to coalescing and
other link service quirks (or bugs) that doesn't happen for every network
change.
This means that we end up calling RebuildSuffixList after every
CheckAdaptersAddresses call, but we don't do that for CheckPlatformDNSStatus.
This patch makes it so that we always call both methods regardless which of
the two observer notifications was received.
Differential Revision: https://phabricator.services.mozilla.com/D56435
--HG--
extra : moz-landing-system : lando
These typically indicate a fatal problem for whatever the page is trying to do;
we should give them the appropriate visibility.
Differential Revision: https://phabricator.services.mozilla.com/D56239
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55444
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55443
--HG--
extra : moz-landing-system : lando
It should be illegal to add paths that cannot be handled/accessed
or later referenced. Without a path, it is for example later
impossible to delete the handler.
To address this we return an NS_ERROR_INVALID_ARG when
nsIHttpServer.registerPathHandler is called with an empty string.
Differential Revision: https://phabricator.services.mozilla.com/D55160
--HG--
extra : moz-landing-system : lando
This patch does the following:
1. Disable flashblock when fission is enabled.
2. Update flashblock tests to expect "unknown" classification when fission is
enabled.
3. Remove skip-if=fission in flashblock mochitests.
Depends on D51098
Differential Revision: https://phabricator.services.mozilla.com/D55091
--HG--
extra : moz-landing-system : lando
We normally get HttpChannelParent::OnStartRequest directly from nsHttpChannel::OnStartRequest, where we disable content conversion and ask the child to do it instead.
When we install a multipart converter, we defer calling HttpChannelParent::OnStartRequest until we've decoded parts, at which point content conversion is already applied to the stream.
This detects that case, and stops the child trying to do it a second time (which fails, and breaks the content).
Differential Revision: https://phabricator.services.mozilla.com/D55222
--HG--
extra : moz-landing-system : lando
We can't always know when sending a part if it'll be the last one (either because the channel is later cancelled, or because the response just sends the end boundary without warning). This was initially reported in bug 339610.
Differential Revision: https://phabricator.services.mozilla.com/D55220
--HG--
extra : moz-landing-system : lando
This also removes OnStartRequestSent from PHttpBackgroundChannel, since there should never be any messages sent earlier on this channel, so we can just assume the waiting state initially.
Differential Revision: https://phabricator.services.mozilla.com/D55219
--HG--
extra : moz-landing-system : lando
Looks like this can sometimes fail with moz-extension URIs, so we shouldn't crash
Differential Revision: https://phabricator.services.mozilla.com/D54249
--HG--
extra : moz-landing-system : lando
Without DocumentChannel, nsExtProtocolChannel::OpenURL calls into nsExternalHelperAppService::LoadURI in the content process.
We then manually forward this to the parent process over PContent, create a RemoteWindowContext around the browser parent, and then call LoadURI again.
With DocumemntChannel, the nsExtProtocolChannel already lives in the parent, so we just need to provide a RemoteWindowContext directly (that the code accesses via GetInterface on the callbacks).
Differential Revision: https://phabricator.services.mozilla.com/D54247
--HG--
extra : moz-landing-system : lando
Looks like this can sometimes fail with moz-extension URIs, so we shouldn't crash
Differential Revision: https://phabricator.services.mozilla.com/D54249
--HG--
extra : moz-landing-system : lando
Without DocumentChannel, nsExtProtocolChannel::OpenURL calls into nsExternalHelperAppService::LoadURI in the content process.
We then manually forward this to the parent process over PContent, create a RemoteWindowContext around the browser parent, and then call LoadURI again.
With DocumemntChannel, the nsExtProtocolChannel already lives in the parent, so we just need to provide a RemoteWindowContext directly (that the code accesses via GetInterface on the callbacks).
Differential Revision: https://phabricator.services.mozilla.com/D54247
--HG--
extra : moz-landing-system : lando
InputStreamShim and OutputStreamShim now hold a strong reference to the callback and it's released after calling nsIInputStreamCallback::OnInputStreamReady() and nsIOutputStreamCallback::OnOutputStreamReady()
Differential Revision: https://phabricator.services.mozilla.com/D54147
--HG--
extra : moz-landing-system : lando
The preferences network.netlink.route.check.IPv4 and network.netlink.route.check.IPv6 were removed in bug 1593693 and the values are now hardcoded because they are used by Linux/Android implementation of nsNetworkLinkService for link status detection and they are not supposed to be changed by the user.
Differential Revision: https://phabricator.services.mozilla.com/D55587
--HG--
extra : moz-landing-system : lando
Looks like this can sometimes fail with moz-extension URIs, so we shouldn't crash
Differential Revision: https://phabricator.services.mozilla.com/D54249
--HG--
extra : moz-landing-system : lando
Without DocumentChannel, nsExtProtocolChannel::OpenURL calls into nsExternalHelperAppService::LoadURI in the content process.
We then manually forward this to the parent process over PContent, create a RemoteWindowContext around the browser parent, and then call LoadURI again.
With DocumemntChannel, the nsExtProtocolChannel already lives in the parent, so we just need to provide a RemoteWindowContext directly (that the code accesses via GetInterface on the callbacks).
Differential Revision: https://phabricator.services.mozilla.com/D54247
--HG--
extra : moz-landing-system : lando
We perform this check in the first OnDataAvailable, instead of doing it in
OnStopRequest in case a network down event occurs after the data has arrived
but before we fire OnStopRequest. That would cause us to report a missing
networkID, even though it was not empty while receiving data.
Differential Revision: https://phabricator.services.mozilla.com/D55574
--HG--
extra : moz-landing-system : lando
Stuff that's infallible and not virtual has no reason to return an nsresult.
Differential Revision: https://phabricator.services.mozilla.com/D54831
--HG--
extra : moz-landing-system : lando
The problem is that the suffix is not always computed when Firefox starts up.
This patch adds a pref `network.notify.initial_call` that controls whether
CheckAdaptersAddresses gets called imediately after.
This call is necessary in order to compute the suffix list, VPN status, etc.
This patch also ensures that OnDnsSuffixListUpdated gets called by
NetlinkService::ComputeDNSSuffixList on Android. This notification is
necessary for the TRRService to pick up the suffix list.
Differential Revision: https://phabricator.services.mozilla.com/D55303
--HG--
extra : moz-landing-system : lando
There's just no use for it, it was an unnecessary virtual interface, with a single concreate class and only ever used in C++.
Differential Revision: https://phabricator.services.mozilla.com/D55069
--HG--
extra : moz-landing-system : lando
Use QueryObject instead. Some variable renaming to make it clearer we are dealing with a http channel.
Differential Revision: https://phabricator.services.mozilla.com/D55238
--HG--
extra : moz-landing-system : lando
CacheEntry::GetAltDataSize() can throw an error if the size isn't known yet, i.e. when the output stream wasn't closed yet. nsHttpChannel::OpenCacheInputStream() doesn't check the return value and in case of failure uninitialized altDataSize is stored in mAltDataLength.
Differential Revision: https://phabricator.services.mozilla.com/D55085
--HG--
extra : moz-landing-system : lando
Updating the PSL while Firefox is running could cause principals to have
a different base domain before/after the update.
See bug 1582647 comment 30
Differential Revision: https://phabricator.services.mozilla.com/D55014
--HG--
extra : moz-landing-system : lando
This allows test toolkit/components/places/tests/browser/browser_multi_redirect_frecency.js and others to pass when fission is enabled.
The content process expects to know the chain of redirects encountered while opening a URI. The DocumentChannelParent gather that information and sends it to the new ContentChild which can then propagate the information to the new nsDocShell.
The data used to only be passed around during same-origin redirects when fission mode was enabled.
In order to allow for move semantics and preventing unnecessary copy of the DocumentChannelRedirect array, we make the nsIChildProcessChannelListener::onChannelReady property C++ only (noscript).
As we have only one concrete nsIChildProcessChannelListener class (ChildProcessListener) and that the unique OnChannelReady implementation is infallible; we really don't need for the method to return nsresult (so we declare it nostdcall). This helps simplify that call.
Differential Revision: https://phabricator.services.mozilla.com/D54909
--HG--
extra : moz-landing-system : lando
A typo prevented for moves to actually occur. Fix other IPDL entry points while at it that could benefit from move semantics.
Depends on D54907
Differential Revision: https://phabricator.services.mozilla.com/D54908
--HG--
extra : moz-landing-system : lando
The patch changes InputStreamShim::AsyncWait() so it checks the buffer state and if there is some data available the callback is immediately notified. Without this check the callback would be notified only when new data is delivered from the network.
Differential Revision: https://phabricator.services.mozilla.com/D53972
--HG--
extra : moz-landing-system : lando
The previous site URI is now only written on the parent and sent back to the child once all redirects have completed.
In a follow up we will also transfer this information when a process switch occur as it's currently broken.
Differential Revision: https://phabricator.services.mozilla.com/D53926
--HG--
extra : moz-landing-system : lando
Rather that setting the property bag on both the child and parent from the docshell; we first set it on the parent instead, and once the redirect (or process switch) has completed we carry that bag across.
Differential Revision: https://phabricator.services.mozilla.com/D53924
--HG--
extra : moz-landing-system : lando
Add static CopyFrom method which is to be used in a follow-up patch. The static method takes a nsIWritablePropertyBag so that we don't need to cast to the concrete class.
Differential Revision: https://phabricator.services.mozilla.com/D53923
--HG--
extra : moz-landing-system : lando
Looks like this can sometimes fail with moz-extension URIs, so we shouldn't crash
Differential Revision: https://phabricator.services.mozilla.com/D54249
--HG--
extra : moz-landing-system : lando
Without DocumentChannel, nsExtProtocolChannel::OpenURL calls into nsExternalHelperAppService::LoadURI in the content process.
We then manually forward this to the parent process over PContent, create a RemoteWindowContext around the browser parent, and then call LoadURI again.
With DocumemntChannel, the nsExtProtocolChannel already lives in the parent, so we just need to provide a RemoteWindowContext directly (that the code accesses via GetInterface on the callbacks).
Differential Revision: https://phabricator.services.mozilla.com/D54247
--HG--
extra : moz-landing-system : lando
Not having a responseHead or browsingContext should not cause a crash or exception
In xpcshell-tests we don't really have a browsingContext, so we want to make
sure we don't crash when that happens.
If the channel failed, we may not have a response head. In that case we don't
want the call to ComputeCrossOriginOpenerPolicyMismatch to be what throws
an exception.
Differential Revision: https://phabricator.services.mozilla.com/D54408
--HG--
extra : moz-landing-system : lando
There are 2 redirections happened on the tracking resource:
`nsHttpChannel` -> `InterceptedHttpChannel` -> `nsHttpChannel`.
`mTopWindowURI` is not copied to during the first redirection because it checks if the target channel is a `nsHttpChannel`.
Differential Revision: https://phabricator.services.mozilla.com/D52181
--HG--
extra : moz-landing-system : lando
There was no need for the ChannelEventQueue and GetNeckoTarget() was always retuning the main thread anyway.
Differential Revision: https://phabricator.services.mozilla.com/D53140
--HG--
extra : moz-landing-system : lando
This expose that some methods aren't doing anything. We will address those in a follow-up change.
Differential Revision: https://phabricator.services.mozilla.com/D52783
--HG--
extra : moz-landing-system : lando
- Adds the `network.trr.enable_when_vpn_detected` defaulting to false. This means detecting a PPP adapter will make IsExcludedFromTRR always return true - it does not affect the `network.trr.mode` pref.
- Adds a test that when nsINetworkLinkService.vpnDetected is true we skip all TRR requests
- Makes it so we update the excludedDomains list and VPN detected status for TRR on any network:link-status-changed observer notification that is received.
Differential Revision: https://phabricator.services.mozilla.com/D53356
--HG--
extra : moz-landing-system : lando
- Since IsExcludedFromTRR may be called from multiple threads we should make sure that the member variables it uses are either atomic or locked.
- Makes IsTRRBlacklisted call IsExcludedFromTRR instead of querying variables again.
- Removes hardcoded checks for localhost and .local, since these are included in network.trr.builtin-excluded-domains
Differential Revision: https://phabricator.services.mozilla.com/D53984
--HG--
extra : moz-landing-system : lando
This patch fixes two issues where we may mistakenly load a TRR record even though the host is part of the excluded-domains list:
1. If a.com is part of the excluded domains, but b.com is not, then when we first resolve b.com using TRR, the server may also push the record for a.com; Previously we didn't check if the pushed record is also excluded, which could lead us to load it from the TRR cache.
2. If b.com is resolved using TRR, but later b.com is added to the excluded-domains list, we may mistakenly load b.com from the TRR cache, even though we should use platform DNS for it.
Differential Revision: https://phabricator.services.mozilla.com/D53354
--HG--
extra : moz-landing-system : lando
Currently DocumentChannelParent serves two fairly separate functions.
It acts as a logic controller for a connecting load (ultimately on behalf of a CanonicalBrowsingContext), that creates a channel and once it gets a response, figures out the right thing to do with it (send to the originating process, send to a new process, handle as a download etc).
It's the parent-side IPDL actor for an nsIChannel implementation that we hold in the docshell as a placeholder while the above happens. This is largely a backwards compatibility hack since docshell expects to have a channel when a load has been initiated (but in the future we could do loads more directly through BrowsingContext and rewrite docshell to understand waiting on that).
This patch splits this into two separate classes (and adds more documentation explaining exactly what each one does). It shouldn't affect any behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D53383
--HG--
rename : netwerk/ipc/DocumentChannelParent.cpp => netwerk/ipc/DocumentLoadListener.cpp
extra : moz-landing-system : lando
- Adds the `network.trr.enable_when_vpn_detected` defaulting to false. This means detecting a PPP adapter will make IsExcludedFromTRR always return true - it does not affect the `network.trr.mode` pref.
- Adds a test that when nsINetworkLinkService.vpnDetected is true we skip all TRR requests
- Makes it so we update the excludedDomains list and VPN detected status for TRR on any network:link-status-changed observer notification that is received.
Differential Revision: https://phabricator.services.mozilla.com/D53356
--HG--
extra : moz-landing-system : lando
This patch makes network change event different from network ID change event on Linux and Android. Network change event is now also sent when any address has been added, removed or changed.
Differential Revision: https://phabricator.services.mozilla.com/D53796
--HG--
extra : moz-landing-system : lando
These two functions both have a large number of arguments that are largely identical (and ones missing from the PContent one are mostly oversights).
Unifying both to take a single argument and return the same result means we can unify the serialization and return value (promise) handling.
Differential Revision: https://phabricator.services.mozilla.com/D53382
--HG--
extra : moz-landing-system : lando
The signatureInfo that has been used in ExternalHelperAppService and
ReputationService has been stored Array of nsIX509CertList, which
isn't necessary because only the raw bytes of the certs are required.
This patch intends to remove the usage of nsIX509CertList and store
the raw bytes directly.
Differential Revision: https://phabricator.services.mozilla.com/D44243
--HG--
extra : moz-landing-system : lando