Thanks to the promisifying of SendCrossProcessRedirect we no longer needs callback to DocumentChannelParent from nsHttpChannelParent. So we can remove the interface that allowed to do so.
Differential Revision: https://phabricator.services.mozilla.com/D46174
--HG--
rename : netwerk/base/nsICrossProcessSwitchChannel.idl => netwerk/base/nsIProcessSwitchRequestor.idl
extra : moz-landing-system : lando
Will allow for SessionStore.jsm process switching to be used by other objects than nsHttpChannel.
Differential Revision: https://phabricator.services.mozilla.com/D46015
--HG--
extra : moz-landing-system : lando
Thanks to the promisifying of SendCrossProcessRedirect we no longer needs callback to DocumentChannelParent from nsHttpChannelParent. So we can remove the interface that allowed to do so.
Differential Revision: https://phabricator.services.mozilla.com/D46174
--HG--
rename : netwerk/base/nsICrossProcessSwitchChannel.idl => netwerk/base/nsIProcessSwitchRequestor.idl
extra : moz-landing-system : lando
Will allow for SessionStore.jsm process switching to be used by other objects than nsHttpChannel.
Differential Revision: https://phabricator.services.mozilla.com/D46015
--HG--
extra : moz-landing-system : lando
In bug 1554242 we're noticing main thread file IO sending a PNG
thumbnail as a blob over IPC. The stack is roughly
IPCBlobInputStream::Close() -> nsFileInputStream::Close() ->
nsFileStreamBase::DoOpen(). The file in question is always a
deferred open file, and we didn't open it in append mode, so there
is no way for ftell to be anything other than 0 (?). This was
verified with an assertion on a try run.
Differential Revision: https://phabricator.services.mozilla.com/D46328
--HG--
extra : moz-landing-system : lando
We should use ~0uL << x instead of ~0L << x because we are working with uint32_t
Differential Revision: https://phabricator.services.mozilla.com/D46213
--HG--
extra : moz-landing-system : lando
When the IPv4 check is completed, we get the network ID and report to telemetry if it was empty or not. This allows us to more accurately determine if we always have a networkID.
Depends on D45331
Differential Revision: https://phabricator.services.mozilla.com/D45332
--HG--
extra : moz-landing-system : lando
Also removes the UA cache attached to nsILoadGroup and nsIRequestContext and the "http-on-useragent-request" observer notification.
If overriding the user agent is needed "http-on-modify-request" is equally usable (but should be used rarely, for performance reasons). A better way is using nsIDocShell.customUserAgent.
Depends on D14750
Differential Revision: https://phabricator.services.mozilla.com/D14751
--HG--
extra : moz-landing-system : lando
Also removes the UA cache attached to nsILoadGroup and nsIRequestContext and the "http-on-useragent-request" observer notification.
If overriding the user agent is needed "http-on-modify-request" is equally usable (but should be used rarely, for performance reasons). A better way is using nsIDocShell.customUserAgent.
Depends on D14750
Differential Revision: https://phabricator.services.mozilla.com/D14751
--HG--
extra : moz-landing-system : lando
If the docshell explicitly set this property with a nullptr value, then we should just return that.
This fixes a warning where we try QI a DocumentChannelChild to nsIHttpChannel when looking for the referrer.
Differential Revision: https://phabricator.services.mozilla.com/D45149
--HG--
extra : moz-landing-system : lando
Also removes the UA cache attached to nsILoadGroup and nsIRequestContext and the "http-on-useragent-request" observer notification.
If overriding the user agent is needed "http-on-modify-request" is equally usable (but should be used rarely, for performance reasons). A better way is using nsIDocShell.customUserAgent.
Depends on D14750
Differential Revision: https://phabricator.services.mozilla.com/D14751
--HG--
extra : moz-landing-system : lando
Removing this check would allow us to see leaked URIs created off main thread.
This is OK because we already use a mutex to guard the linkedList
Differential Revision: https://phabricator.services.mozilla.com/D45156
--HG--
extra : moz-landing-system : lando
This patch adds a new `mIsDelegatedCredential` parameter to nsITransportSecurityInfo, indicating whether or not a delegated credential keypair was used in the TLS handshake (see: https://tools.ietf.org/html/draft-ietf-tls-subcerts-03) .
This functionality is only available if _security.tls.enable_delegated_credentials_ is set to true.
Differential Revision: https://phabricator.services.mozilla.com/D39807
--HG--
extra : moz-landing-system : lando
For now, when we turn on `disable cache` switch in DevTools[1], web page loads
the contents without using the cache. Furthermore, DevTools as well comes to
load the contents DevTools inspects without using the cache. And, if the loaded
contents from the web page and DevTools was different, becomes impossible to
inspect the content correctly.
Thus, in order to make DevTools refer the same content the web page loaded,
makes DevTools load the contents inspecting from the cache at first, no matter
if disables the switch or not.
When turns on disable cache in DevTools, `LOAD_BYPASS_CACHE` flag is set into
`loadFlags` in the `docshell`.[2] The other hand, the content DevTools inspects
is loaded from a channel DevTools creates with `LOAD_FROM_CACHE` flag.[3]
However, because this channel is belong to same `loadGroup` of the `docshell`,
`LOAD_BYPASS_CACHE` is inherited and is choosen even if `LOAD_FROM_CACHE` is set.
Thus, in this patch, we introduce an attribute `preferCacheLoadOverBypass`
which raises the priority for `LOAD_FROM_CACHE` above `LOAD_BYPASS_CACHE` and
`LOAD_BYPASS_LOCAL_CACHE`.
[1] https://developer.mozilla.org/en-US/docs/Tools/Settings#Advanced_settings
[2] https://searchfox.org/mozilla-central/source/devtools/server/actors/targets/browsing-context.js#1227
[3] https://searchfox.org/mozilla-central/source/devtools/shared/DevToolsUtils.js#542-544
Differential Revision: https://phabricator.services.mozilla.com/D44626
--HG--
extra : moz-landing-system : lando
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
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 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
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
