This is likely not the best approach to detecting IP connectivity.
The check has a slight delay until the failure counter reaches the threshold.
A more reliable way will be added in a follow-up.
Depends on D7844
Differential Revision: https://phabricator.services.mozilla.com/D8704
--HG--
extra : moz-landing-system : lando
Sometimes nsIBinaryInputStream.readByteArray could return NS_BASE_STREAM_WOULD_BLOCK.
In this case we want to retry reading from the input stream.
Differential Revision: https://phabricator.services.mozilla.com/D9900
--HG--
extra : moz-landing-system : lando
This is likely not the best approach to detecting IP connectivity.
The check has a slight delay until the failure counter reaches the threshold.
A more reliable way will be added in a follow-up.
Depends on D7844
Differential Revision: https://phabricator.services.mozilla.com/D8704
--HG--
extra : moz-landing-system : lando
This allows some code to be deleted, including a KnownModule ctor.
Depends on D8168
Differential Revision: https://phabricator.services.mozilla.com/D8169
--HG--
extra : moz-landing-system : lando
The test ocasionally fails out in e10s mode, because stream.available() might not return the entire string length (it's async). So the child process needs to wait for all of the bytes to be read.
Differential Revision: https://phabricator.services.mozilla.com/D9274
--HG--
extra : moz-landing-system : lando
By setting network.dns.native-is-localhost in this test, it makes all native
name resolves use "localhost" and thus avoids causing an assert if this test
runs with TRR enabled and network.trr.uri set to point to an actual external
host name.
MozReview-Commit-ID: D1df6VtfckR
Differential Revision: https://phabricator.services.mozilla.com/D9070
--HG--
extra : moz-landing-system : lando
In trying to use fetch with alt-data, we sometimes want the benefit of using alt-data but the JS consumer actually needs to use the original HTTP response from the server.
To get around this problem, we introduce a new API - nsICacheInfoChannel.getOriginalInputStream(nsIInputStreamReceiver) that asyncly receives the input stream containing the HTTP response in the cache entry.
Depends on D8071
Differential Revision: https://phabricator.services.mozilla.com/D8072
--HG--
extra : rebase_source : 43d92c631b964c52b551a700b0954276e91695d6
extra : source : 7f9d03c29a6ffd82c1b5e17c14e27a2ae9d64434
This patch changes the way we set and handle the preferred alternate data type.
It is no longer just one choice, but a set of preferences, each conditional
on the contentType of the resource.
For example:
var cc = chan.QueryInterface(Ci.nsICacheInfoChannel);
cc.preferAlternativeDataType("js-bytecode", "text/javascript");
cc.preferAlternativeDataType("ammended-text", "text/plain");
cc.preferAlternativeDataType("something-else", "");
When loaded from the cache, the available alt-data type will be checked against
"js-bytecode" if the contentType is "text/javascript", "ammended-text" if the contentType is "text/plain" or "something-else" for all contentTypes.
Note that the alt-data type could be "something-else" even if the contentType is "text/javascript".
The preferences are saved as an nsTArray<mozilla::Tuple<nsCString, nsCString>>.
Differential Revision: https://phabricator.services.mozilla.com/D8071
--HG--
extra : rebase_source : eb4961f05a52e557e7d2d986d59e0a2cf18a3447
extra : source : dd1c31ea78c2b15d14750d137037a54d50719997
This allows some code to be deleted, including a KnownModule ctor.
Depends on D8168
Differential Revision: https://phabricator.services.mozilla.com/D8169
--HG--
extra : moz-landing-system : lando
In trying to use fetch with alt-data, we sometimes want the benefit of using alt-data but the JS consumer actually needs to use the original HTTP response from the server.
To get around this problem, we introduce a new API - nsICacheInfoChannel.getOriginalInputStream(nsIInputStreamReceiver) that asyncly receives the input stream containing the HTTP response in the cache entry.
Depends on D8071
Differential Revision: https://phabricator.services.mozilla.com/D8072
--HG--
extra : moz-landing-system : lando
This patch changes the way we set and handle the preferred alternate data type.
It is no longer just one choice, but a set of preferences, each conditional
on the contentType of the resource.
For example:
var cc = chan.QueryInterface(Ci.nsICacheInfoChannel);
cc.preferAlternativeDataType("js-bytecode", "text/javascript");
cc.preferAlternativeDataType("ammended-text", "text/plain");
cc.preferAlternativeDataType("something-else", "");
When loaded from the cache, the available alt-data type will be checked against
"js-bytecode" if the contentType is "text/javascript", "ammended-text" if the contentType is "text/plain" or "something-else" for all contentTypes.
Note that the alt-data type could be "something-else" even if the contentType is "text/javascript".
The preferences are saved as an nsTArray<mozilla::Tuple<nsCString, nsCString>>.
Differential Revision: https://phabricator.services.mozilla.com/D8071
--HG--
extra : moz-landing-system : lando
If class A is derived from class B, then an instance of class A can be
converted to B via a static cast, so a slower QI is not needed.
Differential Revision: https://phabricator.services.mozilla.com/D6861
--HG--
extra : moz-landing-system : lando
The templated version of Finalize is not needed, because the argument
being passed in is already an nsIURI, so the QI is not needed.
Differential Revision: https://phabricator.services.mozilla.com/D6862
--HG--
extra : moz-landing-system : lando
Move all fields of nsISSLStatus to nsITransportSecurityProvider
Remove nsISSLStatus interface and definition
Update all code and test references to nsISSLStatus
Maintain ability to read in older version of serialized nsISSLStatus. This
is verified with psm_DeserializeCert gtest.
Differential Revision: https://phabricator.services.mozilla.com/D3704
--HG--
extra : moz-landing-system : lando
Move all fields of nsISSLStatus to nsITransportSecurityProvider
Remove nsISSLStatus interface and definition
Update all code and test references to nsISSLStatus
Maintain ability to read in older version of serialized nsISSLStatus. This
is verified with psm_DeserializeCert gtest.
Differential Revision: https://phabricator.services.mozilla.com/D3704
--HG--
extra : moz-landing-system : lando
This patch builds the foundation for the ability to relocate HTTP channels from one content process to another in order to ensure that origins are properly isolated. This relocation would normally occur when the response to an HTTP request is a redirect to a different origin.
The patch merely adds the mechanism for relocating the channel, rather than the logic of doing so. This will be provided in a follow-up patch by a specialized service. Right now that functionality is mocked in the test.
How this works:
In nsHttpChannel::OnStartRequest we will query the service that decides whether we need to direct the response to another process. If so, it will return a promise that resolves to a TabParent.
When the promise resolves, in HttpChannelParentListener::TriggerCrossProcessRedirect we call NeckoParent::SendCrossProcessRedirect passing along the required information to recreate the channel in the new process. The NeckoChild in the new process will then instantiate a new channel, call ConnectParent() which creates the associated parent channel, and connects it with the existing nsHttpChannel.
A listener in the new process is then notified of the existence of the new channel. It is required to call completeRedirectSetup on the channel, passing an nsIStreamListener to the call.
We then finish the entire operation with a call to HttpChannelChild::SendCrossProcessRedirectDone which causes us to close the old HttpChannelChild in the previous process and to resume the nsHttpChannel in the main process.
Differential Revision: https://phabricator.services.mozilla.com/D2958
--HG--
rename : netwerk/test/browser/browser_cookie_sync_across_tabs.js => netwerk/test/browser/browser_cross_process_redirect.js
rename : dom/media/test/redirect.sjs => netwerk/test/browser/redirect.sjs
extra : moz-landing-system : lando
