So that we can restrict QI(nsIIdentChannel) to nsIHttpChannel and DocumentChannelChild objects only.
Differential Revision: https://phabricator.services.mozilla.com/D44111
MANUAL PUSH: multiple authors stack
DocumentChannel acts as a replacement for HttpChannel where redirects are now entirely handled in the DocumentChannelParent. The ContentChild will receive the final nsIChannel once all redirects have been handled.
Differential Revision: https://phabricator.services.mozilla.com/D37490
We can deduct it from the nsIChannel argument already. In the future, the httpParent may be either HttpChannelParent or DocumentChannelParent.
Differential Revision: https://phabricator.services.mozilla.com/D40971
The devtools listens to http-on-opening-request event which is expected to receive a nsIHttpChannel. However future changes will make it that it's not always a nsIHttpChannel that can fire such event.
As such we create an intermediary interface nsIIdentChannel and move the subset generating such event in nsIHttpChannel there.
Differential Revision: https://phabricator.services.mozilla.com/D40968
This more closely follow the code as earlier documented. To remove all ambiguities, the idl documentation was amended.
Differential Revision: https://phabricator.services.mozilla.com/D40961
This class allows to encapsulate all the information required in order to create a new HttpChannel object following a redirect.
Differential Revision: https://phabricator.services.mozilla.com/D40959
This removes a rather verbose warning during URI mutation. This often
happens for use cases such as attempting to clear the field. Since `Finalize`
is marked as `MOZ_MUST_USE` we can be confident that any failures that used
to be warned about are properly handled.
Differential Revision: https://phabricator.services.mozilla.com/D42384
--HG--
extra : moz-landing-system : lando
As part of the ongoing effort to port the nsIWebProgress events from
RemoteWebProgress / WebProgressChild to BrowserParent / BrowserChild, we need
to (de)serialize the nsITransportSecurityInfo instance across the IPC layer.
The existing code was calling `NS_SerializeToString` which has the overhead of
(a) allocating a buffer and also performing base64 encoding/decoding. This
patch adds `IPC::ParamTraits` implementations for `nsITransportSecurityInfo`,
`nsIX509Certificate`, and `nsIX509CertList` that (de)serializes the params
directly onto and off of the IPC message so that we don't go through the
overhead of allocating and encoding/decoding an additional buffer.
This (de)serialization will address the performance issues present in the
current implementation.
As a side effect, I also make nsITransportSecurityInfo a builtinclass XPCOM
interface, since the existing serialization code was assuming it was, there is
only one implementation, and it is in C++.
Differential Revision: https://phabricator.services.mozilla.com/D35090
--HG--
extra : moz-landing-system : lando
As part of the ongoing effort to port the nsIWebProgress events from
RemoteWebProgress / WebProgressChild to BrowserParent / BrowserChild, we need
to (de)serialize the nsITransportSecurityInfo instance across the IPC layer.
The existing code was calling `NS_SerializeToString` which has the overhead of
(a) allocating a buffer and also performing base64 encoding/decoding. This
patch adds `IPC::ParamTraits` implementations for `nsITransportSecurityInfo`,
`nsIX509Certificate`, and `nsIX509CertList` that (de)serializes the params
directly onto and off of the IPC message so that we don't go through the
overhead of allocating and encoding/decoding an additional buffer.
This (de)serialization will address the performance issues present in the
current implementation.
As a side effect, I also make nsITransportSecurityInfo a builtinclass XPCOM
interface, since the existing serialization code was assuming it was, there is
only one implementation, and it is in C++.
Differential Revision: https://phabricator.services.mozilla.com/D35090
--HG--
extra : moz-landing-system : lando
When URL Classifier reports a channel is a tracker, we should only notify the classification
result when it is a third-party channel.
That means, |IsAllowListed| should not take into consideation here.
Differential Revision: https://phabricator.services.mozilla.com/D43735
--HG--
extra : moz-landing-system : lando
This patch implements NetlinkService which communicates with kernel via netlink socket. It keeps track of addresses, default routes, interfaces and neighbors and uses it to calculate network ID.
Differential Revision: https://phabricator.services.mozilla.com/D43175
--HG--
rename : netwerk/system/linux/nsNotifyAddrListener_Linux.cpp => netwerk/system/linux/nsNetworkLinkService.cpp
rename : netwerk/system/linux/nsNotifyAddrListener_Linux.h => netwerk/system/linux/nsNetworkLinkService.h
extra : moz-landing-system : lando
This patch implements NetlinkService which communicates with kernel via netlink socket. It keeps track of addresses, default routes, interfaces and neighbors and uses it to calculate network ID.
Differential Revision: https://phabricator.services.mozilla.com/D43175
--HG--
rename : netwerk/system/linux/nsNotifyAddrListener_Linux.cpp => netwerk/system/linux/nsNetworkLinkService.cpp
rename : netwerk/system/linux/nsNotifyAddrListener_Linux.h => netwerk/system/linux/nsNetworkLinkService.h
extra : moz-landing-system : lando
