IDLE markers help with categorizing threads in the profiler UI.
_SLEEP makes the profiler spend less time sampling threads that haven't changed.
Differential Revision: https://phabricator.services.mozilla.com/D10815
--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 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
We may need this function to convert ReferrerPolicy enum to string then
we can display referrer policy applied to a request.
MozReview-Commit-ID: B3xPAiykcOV
Differential Revision: https://phabricator.services.mozilla.com/D9664
--HG--
extra : moz-landing-system : lando
This is a straightforward patch.
Just add a new attribute in nsIProtocolProxyService to indicate whether PAC is still loading. If yes, fail the OCSP request.
Differential Revision: https://phabricator.services.mozilla.com/D9154
--HG--
extra : moz-landing-system : lando
This patch addresses a bug introduced in the solution to Bug 356831, in which
the back-off time for reloading PAC files was set to the shortest interval every time a failure happened, thus auto-detecting PAC every 5 seconds
on a network on which WPAD did not resolve when the proxy was set to auto-detect.
The changes in this patch are:
* nsPACMan.h - declares a private overload to LoadPACFromURI, with an
additional parameter called aResetLoadFailureCount.
* nsPACMan.cpp - moves the implementation of the old LoadPACFromURI to the new
private overload, with the modification that the mLoadFailureCount field
is only reset to 0 if aResetLoadFailureCount is true. Replaces the
implementation of the public LoadPACFromURI with a call to the private overload
with aResetLoadFailureCount = true. Also replaces the call made from within
nsPACMan when triggering an internal reload with a call with
aResetLoadFailureCount = false, thus ensuring that internally triggered reloads
do not reset the back-off time.
Differential Revision: https://phabricator.services.mozilla.com/D9035
--HG--
extra : moz-landing-system : lando
In the current code there are 3 main issues:
1. nsFileStream is not really thread-safe. There is nothing to protect the
internal members and we see crashes.
2. nsPipeInputStream doesn't implement ::Seek() method and that caused issues
in devtools when a nsHttpChannel sends POST data using a pipe. In order to fix
this, bug 1494176 added a check in nsHttpChannel: if the stream doesn't
implement ::Seek(), let's clone it. This was an hack around nsPipeInputStream,
and it's bad.
3. When nsHttpChannel sends POST data using a file stream, nsFileStream does
I/O on main-thread because of the issue 2. Plus, ::Seek() is called on the
main-thread causing issue 1.
Note that nsPipeInputStream implements only ::Tell(), of the nsISeekableStream
methods. It doesn't implement ::Seek() and it doesn't implement ::SetEOF().
With this patch I want to fix point 2 and point 3 (and consequentially issue 1
- but we need a separate fix for it - follow up). The patch does:
1. it splits nsISeekableStream in 2 interfaces: nsITellableStream and
nsISeekableStream.
2. nsPipeInputStream implements only nsITellableStream. Doing this, we don't
need the ::Seek() check for point 2 in nsHttpChannel: a simple QI check is
enough.
3. Because we don't call ::Seek() in nsHttpChannel, nsFileStream doesn't do I/O
on the main-thread, and we don't crash doing so.
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
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
The first QI is never used. The second one is the same as the one in
nsCOMPtr.h, so we should be able to call that instead, which can be
done simply by deleting the method. The motivation is that I'm
changing how do_QueryInterface works, and I'd like to avoid changing
this place given that it isn't actually needed.
Differential Revision: https://phabricator.services.mozilla.com/D7528
--HG--
extra : moz-landing-system : lando
Gurzau Raul
Ehsan Akhgari
Cosmin Sabou
Gerald Squelart
Ciure Andrei
Thomas Nguyen
Gabriele Svelto
Jonathan Kingston
Dragana Damjanovic
Andreea Pavel
Narcis Beleuzu
Valentin Gosu
Andrea Marchesini
Junior Hsu
Daniel Stenberg
Coroiu Cristina
Daniel Varga
James Lee
Kershaw Chang
Polly Shaw
Dorel Luca
Henri Sivonen
Diego Pino Garcia
Andrew McCreight