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 fixes the regression caused by bug 1500549.
MozReview-Commit-ID: 3VBvIbrEbDT
Differential Revision: https://phabricator.services.mozilla.com/D9526
--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
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
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
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.
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
Right now, we have no idea how often an origin may offer us multiple alt-svc options. As we are considering racing multiple alt-svc connections (if they're available), it would be good to know how often we actually have (or would have, were we to store them) multiple options available. It would also be good to know how often an origin may change the target of its alt-svc mapping (even if there is only one target), as changes in target may make it useful to store/race multiple targets, as well.
Differential Revision: https://phabricator.services.mozilla.com/D8878
--HG--
extra : moz-landing-system : lando
How often is a successful (native) resolve delayed by a preceeding TRR
failure. (Replaces DNS_TRR_FIRST)
MozReview-Commit-ID: Da8oH53CZTs
Differential Revision: https://phabricator.services.mozilla.com/D8060
--HG--
extra : moz-landing-system : lando
Right now, as soon as we receive an alt-svc header or frame for an origin, we will overwrite any mapping we already have for that origin, even if it's still valid. This means that, should validation fail for the new mapping, we will have blown away a perfectly usable alt-svc mapping for no good reason. This patch prevents us from overwriting until we know the new mapping is good.
Differential Revision: https://phabricator.services.mozilla.com/D8747
--HG--
extra : moz-landing-system : lando
OPTIONS preflights inherit the original request's referrer and referrer policy
Differential Revision: https://phabricator.services.mozilla.com/D7801
--HG--
extra : moz-landing-system : lando
This moves the check for a non-http proxy from the socket transport callbacks in
nsHttpConnection to nsHttpChannel before the connection occurs.
MozReview-Commit-ID: CJIozDInXWz
"Gecko trail" is the term used by MDN [1] for the YYYMMDD build date in the UA string's "Gecko/" token. Build ID is a YYYYMMDDHHMMSS build timestamp. Use LEGACY_BUILD_ID to spoof navigator.buildID. Use LEGACY_UA_GECKO_TRAIL to construct the UA string.
[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox
Differential Revision: https://phabricator.services.mozilla.com/D7983
--HG--
extra : rebase_source : e2a4d7579d419046f0bad6290078f9a652a770d8
extra : source : 8a26c8598528722a8920513c7fdfea40aefe0dbc
This fixes bug introduced by patch from bug 1337893. Serialized origin attributes suffix should be appended instead of rewriting the string.
--HG--
extra : rebase_source : a8ab785102e6e080f3038c1bd94f2b8b82404a55
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
Bug 356831 added a release assert that when performing WPAD the network.proxy.type pref is always 4 (PROXYCONFIG_WPAD).
However, when changing the pref, the runnable is scheduled to run before the PAC thread is shutdown, so it will see the pref that is not PROXYCONFIG_WPAD, while attempting to do WPAD. To avoid this situation, we simply exit early when we detect the wrong pref value.
Differential Revision: https://phabricator.services.mozilla.com/D7617
--HG--
extra : moz-landing-system : lando
refactor some code into the search service. This is necessary to
allow the searchservice to pull multiple locales or regions from a single
extension, based on data the searchservice maintains.
Differential Revision: https://phabricator.services.mozilla.com/D7632
--HG--
extra : moz-landing-system : lando
Previously, we had not put pushed streams in the priority tree, we just
let them be top-level items in the tree. With this change, we will put
them into the tree initially based on the priority of the associated
stream. The only exception is if the associated stream is either a
Leader or Urgent Start (in which case, we will turn the pushed streams
into followers).
Once the pushed stream is matched with a request generated by gecko,
that pushed stream will be re-prioritized based on the priority gecko
has for the request, just like a regular pulled stream.
This also allows us to re-prioritize pushed streams into the background
on tab switch (we assume that, before they are matched, they belong to
the same window as the associated stream).
Differential Revision: https://phabricator.services.mozilla.com/D7223
--HG--
extra : moz-landing-system : lando
Calls to do_QueryInterface to a base class can be replaced by a static
cast, which is faster.
Differential Revision: https://phabricator.services.mozilla.com/D7224
--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
There was an earlier fix to this, that fixed part of the issue, but that
fix was racy. In the case where the transaction was matched with the
pushed stream before the pushed stream received its END_STREAM, and the
response headers did not include a content-length, the transaction would
never notice that the data was done being sent. When that transaction
was necessary for the load event to fire, the page would get stuck in
the loading state until the user explicitly cancelled.
This new patch ensures that the transaction will notice the EOS by
making sure the pushed stream gets inserted into the list of push
streams with data in the case described above. (The previous patch,
which is still in the tree, is still necessary, but not sufficient, to
fix the issue.)
Differential Revision: https://phabricator.services.mozilla.com/D7298
--HG--
extra : moz-landing-system : lando
called if not explicitly requested by the user prefs
The author did not isolate and fix the cause of the assertion failure,
but put in further diagnostics.The author did not isolate and fix the cause of the assertion failure,
but put in further diagnostics.
* an additional assertion was put in on the main thread (which if
triggered would reveal the stack trace)
* in one place where a previously a failure to read the network.proxy.type pref
was ignored, execution of WPAD is now halted with a warning.
Besides these improved diagnostics, in nsPACMan::LoadPACFromURI where an
asynchronous call was made to nsPACMan::StartLoading *before* the preconditions
for this call are set up was changed to be the other way around. The author
suspects that the previous code may have led to race conditions when
LoadPACFromURI was not called from the main thread, although it is not obvious
that this would have caused such a crash.
Differential Revision: https://phabricator.services.mozilla.com/D5388
--HG--
extra : moz-landing-system : lando
The test used to assume that the load event didn't matter and so
the expected values had to be updated to match the new behavior.
A new "slowIFrame" test was added to capture what was previously
tested by the "badIFrame".
Differential Revision: https://phabricator.services.mozilla.com/D7031
--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
Split nsHostRecord into AddrHostRecord and TypeHostRecord for standard address dns queries and queries by-type.
Differential Revision: https://phabricator.services.mozilla.com/D6130
--HG--
extra : moz-landing-system : lando
This also removes the (afaict, unused) stub implementation from TabParent. The netwerk header
inclusions were necessary because those files included TabParent.h and through it,
nsISecureBrowserUI, but now TabParent.h no longer does that.
Differential Revision: https://phabricator.services.mozilla.com/D6829
--HG--
extra : moz-landing-system : lando
Previously, if script tried to set a cookie that matched a cookie we had
received via Set-Cookie that was labeled httponly, script would think
that cookie was properly set (even though it wasn't). This ensures that
script knows just enough about httponly cookies to prevent this
inconsistent view while avoiding leakages of the potentially-sensitive
cookie values.
Differential Revision: https://phabricator.services.mozilla.com/D5700
--HG--
extra : moz-landing-system : lando
Remove various calls to SetCapacity() that fall into various misuse categories:
1) Mistakenly believing that the caller should advice the string about zero
terminator.
2) Cases where a single append does the right computation on its own.
3) Calling SetCapacity() with a constant when the string is self-allocated
and could be an nsAuto[C]StringN and the string doesn't get passed on
in a way that could benefit from a heap-allocated buffer.
4) Calling SetCapacity() before assigning a shared buffer to the string.
5) Calling SetCapacity() before calling a function that will either calls
SetLength() anyway or calls Adopt().
MozReview-Commit-ID: IKjfl5gLmcD
Differential Revision: https://phabricator.services.mozilla.com/D4672
--HG--
extra : moz-landing-system : lando
Simply replace the nsCString with nsDependentCSubstring to avoid copying the data. In this way, we can also avoid the potential OOM crash.
Differential Revision: https://phabricator.services.mozilla.com/D6685
--HG--
extra : moz-landing-system : lando
Right now, pushed streams don't get put in the priority hierarchy
anyway, and with the code as it was, we were sending an illegal PRIORITY
frame for stream 0. This prevents that from happening. We should
probably think about putting pushed streams in the priority hierarchy at
some point.
Differential Revision: https://phabricator.services.mozilla.com/D6500
--HG--
extra : moz-landing-system : lando
Most of the times when we automatically create nsThread wrappers for threads
that don't already have them, we don't actually need the event targets, since
those threads don't run XPCOM event loops. Aside from wasting memory, actually
creating these event loops can lead to leaks if a thread tries to dispatch a
runnable to the queue which creates a reference cycle with the thread.
Not creating the event queues for threads that don't actually need them helps
avoid those foot guns, and also makes it easier to figure out which treads
actually run XPCOM event loops.
MozReview-Commit-ID: Arck4VQqdne
--HG--
extra : source : a03a61d6d724503c3b7c5e31fe32ced1f5d1c219
extra : intermediate-source : 5152af6ab3e399216ef6db8f060c257b2ffbd330
extra : histedit_source : ef06000344416e0919f536d5720fa979d2d29c66%2C4671676b613dc3e3ec762edf5d72a2ffbe6fca3f
Most of the times when we automatically create nsThread wrappers for threads
that don't already have them, we don't actually need the event targets, since
those threads don't run XPCOM event loops. Aside from wasting memory, actually
creating these event loops can lead to leaks if a thread tries to dispatch a
runnable to the queue which creates a reference cycle with the thread.
Not creating the event queues for threads that don't actually need them helps
avoid those foot guns, and also makes it easier to figure out which treads
actually run XPCOM event loops.
MozReview-Commit-ID: Arck4VQqdne
--HG--
extra : rebase_source : fcf8fa50e748c4b54c3bb1997575d9ffd4cbaae1
extra : source : a03a61d6d724503c3b7c5e31fe32ced1f5d1c219
This replaces the tunnel using a new nr_socket implementation. Proxy detection
code is still done in the peer connction. However, the result is only used to
detect a proxy. The result is unused. Address resolution is done by necko code
in the parent process. The new socket wraps a WebrtcProxyChannel which uses
necko to handle proxy negotiation. This has a happy side effect of enabling all
authentication modes that necko already supports for http proxies.
This adds a protocol for Necko to manage, WebrtcProxyChannel. This new protocol
serves as a pipe for a CONNECT tunnel. It is only used in WebRtc and not built
in no WebRtc builds.
--HG--
extra : rebase_source : a951841f95eaaa0562886cf76b405b01f1adf70e
extra : intermediate-source : 5c3da21957fc80b07188bc8a405437b858027a22
extra : source : 594a32883463ab051677ba06e22fa6d062b4b4a9
Necko does not allow for a CONNECT only request to happen. This adds a flag
to signal an http channel should only CONNECT if proxied. This flag can only be
set if an HTTPUpgrade handler has been assigned. As proposed by rfc7639, an
alpn header will be included in the CONNECT request. Its value is determined by
the upgrade protocol passed to HTTPUpgrade.
The flag is added as part of nsIHttpChannelInternal because it is dependent on
HTTPUpgrade. It exists as a capability flag since the channel's transaction
needs to know to complete after a successful CONNECT. Also the transaction's
connection needs to know to stop writing transaction data after it CONNECTs or
if there's no proxy, and to not tell the transaction to reset.
If an nsHttpChannel has this flag set then the upgrade handler will receive the
socket after the CONNECT succeeds without doing tls if https.
In order to support xpcshell-test for this change, nsHttpConnectionMgr does a
little check to see if HTTPUpgrade callback is in JavaScript. If it is then
the callback is invoked on the main thread.
--HG--
extra : rebase_source : 96cdfe0e1ffe2f7dad7d12c83c22be92d118195a
extra : intermediate-source : 70710e9bf3d98488485c3265ebdea09683a42a80
extra : source : 25b4b531c10c4b2dae416fd7d744a63a32fed7e5
Everything that goes in a PLDHashtable (and its derivatives, like
nsTHashtable) needs to inherit from PLDHashEntryHdr. But through a lack
of enforcement, copy constructors for these derived classes didn't
explicitly invoke the copy constructor for PLDHashEntryHdr (and the
compiler didn't invoke the copy constructor for us). Instead,
PLDHashTable explicitly copied around the bits that the copy constructor
would have.
The current setup has two problems:
1) Derived classes should be using move construction, not copy
construction, since anything that's shuffling hash table keys/entries
around will be using move construction.
2) Derived classes should take responsibility for transferring bits of
superclass state around, and not rely on something else to handle that.
The second point is not a huge problem for PLDHashTable (PLDHashTable
only has to copy PLDHashEntryHdr's bits in a single place), but future
hash table implementations that might move entries around more
aggressively would have to insert compensation code all over the
place. Additionally, if moving entries is implemented via memcpy (which
is quite common), PLDHashTable copying around bits *again* is
inefficient.
Let's fix all these problems in one go, by:
1) Explicitly declaring the set of constructors that PLDHashEntryHdr
implements (and does not implement). In particular, the copy
constructor is deleted, so any derived classes that attempt to make
themselves copyable will be detected at compile time: the compiler
will complain that the superclass type is not copyable.
This change on its own will result in many compiler errors, so...
2) Change any derived classes to implement move constructors instead of
copy constructors. Note that some of these move constructors are,
strictly speaking, unnecessary, since the relevant classes are moved
via memcpy in nsTHashtable and its derivatives.
This removes the rarely used and somewhat odd
`iterator& BeginWriting/EndWriting(iterator&)` functions that take an iterator
as an in/out param and then return it.
--HG--
extra : rebase_source : 92066f996595e9b7df9642813c08592cee47c630
This switches over the few remaining usages of the deprecated
BeginWriting/EndWriting(iterator&) functions to the more standard
BeginWriting/EndWriting() functions.
--HG--
extra : rebase_source : 3c54621d4921eb45157ec4edce0b693bdd7f02d5
