Most of these tests have been disabled for a long time; they run well
in the current test environment.
Differential Revision: https://phabricator.services.mozilla.com/D46642
--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
nsViewSourceChannel will never trigger a change of process. So we can remove this interface from nsViewSourceChannel.
Differential Revision: https://phabricator.services.mozilla.com/D46160
--HG--
extra : moz-landing-system : lando
Similar to MozPromise::FromGeckoResult.
Allows to create a MozPromise that will be resolved/rejected when the JS promise does the same.
It would be nice to be able to chain the two promise types, but it would be an additional effort.
MozPromise::FromDomPromise is limited to primitive types only and the reject value type must be nsresult.
Differential Revision: https://phabricator.services.mozilla.com/D46017
--HG--
extra : moz-landing-system : lando
There's only one consumer of these promises. It doesn't need to be non-exclusive.
Differential Revision: https://phabricator.services.mozilla.com/D46016
--HG--
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
This is a stepped transition ; as SessionStore currently only knows how to deal with nsHttpChannel we have to go through the redirect only if the current channel is a nsHttpChannel.
In a followup change we will allow SessionStore to directly deal with the DocumentParentProcess.
Differential Revision: https://phabricator.services.mozilla.com/D46014
--HG--
extra : moz-landing-system : lando
Patch changes nsAndroidNetworkLinkService so it uses NetlinkService for network ID calculation as well as for notifications about network changes.
Differential Revision: https://phabricator.services.mozilla.com/D43385
--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
nsViewSourceChannel will never trigger a change of process. So we can remove this interface from nsViewSourceChannel.
Differential Revision: https://phabricator.services.mozilla.com/D46160
--HG--
extra : moz-landing-system : lando
Similar to MozPromise::FromGeckoResult.
Allows to create a MozPromise that will be resolved/rejected when the JS promise does the same.
It would be nice to be able to chain the two promise types, but it would be an additional effort.
MozPromise::FromDomPromise is limited to primitive types only and the reject value type must be nsresult.
Differential Revision: https://phabricator.services.mozilla.com/D46017
--HG--
extra : moz-landing-system : lando
There's only one consumer of these promises. It doesn't need to be non-exclusive.
Differential Revision: https://phabricator.services.mozilla.com/D46016
--HG--
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
This is a stepped transition ; as SessionStore currently only knows how to deal with nsHttpChannel we have to go through the redirect only if the current channel is a nsHttpChannel.
In a followup change we will allow SessionStore to directly deal with the DocumentParentProcess.
Differential Revision: https://phabricator.services.mozilla.com/D46014
--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
In places where profiler_is_active() was used around a profiler_add_marker() (or
similar) call, replace it with profiler_can_accept_markers().
Differential Revision: https://phabricator.services.mozilla.com/D44435
--HG--
extra : moz-landing-system : lando
The thread calls into some windows APIs that may sometimes block for a long time. Since we're shutting down anyway, it is OK to sometimes leak this thread, similar to what we do for DNS resolver threads.
The patch converts nsNotifyAddrListener::mThread to a nsIThreadPool (with a max of 1 thread) so that we may call shutdownWithTimeout on it.
Differential Revision: https://phabricator.services.mozilla.com/D46002
--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
Since we sometimes coalesce SendEvents, calling it from there is not actually correct, and sometimes we fail to recompute the networkID when network changes happen.
Differential Revision: https://phabricator.services.mozilla.com/D45331
--HG--
extra : moz-landing-system : lando
In places where profiler_is_active() was used around a profiler_add_marker() (or
similar) call, replace it with profiler_can_accept_markers().
Differential Revision: https://phabricator.services.mozilla.com/D44435
--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
DocumentChannel doesn't use the REDIRECT_INTERNAL flag when replacing itself with a real channel if there has been a real redirect handled in the parent.
This is so that the docshell knows about the URI change, and to add history entries.
The timing data however always wanted to be treated as an internal redirect, so that we don't record a new 'redirectEnd' at the time of the switch.
This adds a new parameter to ConfigureReplacementChannel so that we can more accurately describe the behaviour we need.
Differential Revision: https://phabricator.services.mozilla.com/D45150
--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
In FtpChannelParent, we didn't propagate the channel status to FtpChannelChild. This could make child start to do diversion on a failed channel.
Like what we did in http channel, we should send the channel status to child via OnStartRequest message.
Differential Revision: https://phabricator.services.mozilla.com/D45648
--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
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
This will change RemoveCookiesFromRootDomain to not remove cookies from all sub-domains but instead
only remove the single host that is passed. This is necessary to support removing all sub-domain
cookie data in ForgetAboutSite without compromising on the cookie permissions that are supported by
Sanitizer.jsm
As a side effect, this also fixes the issues described in https://bugzilla.mozilla.org/show_bug.cgi?id=1515913#c24
(which were caused by deleting sub-domains without checking their permission).
Sanitizer.jsm should retain its functionality even with this change, because it already collects
all the principals we have to delete individually and tries to delete them (so it would consider
mozilla.org and support.mozilla.org separately).
Differential Revision: https://phabricator.services.mozilla.com/D45012
--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
