This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13371
--HG--
extra : moz-landing-system : lando
All instances of nsIBrowserSearchService::currentEngine have been replaced by nsIBrowserSearchService::defaultEngine. Dropping this variable now.
Differential Revision: https://phabricator.services.mozilla.com/D12223
--HG--
extra : moz-landing-system : lando
Since we need the loadInfo to set up the IPDL connection, we move the logic to
do so from HttpChannelChild::AsyncOpen to HttpChannelChild::SetLoadInfo
via InitIPCChannel.
It would have been nicer to do so in HttpChannelChild::Init, but
I ran into issues with view-source channels, which required an ugly hack.
Also note that RemoteChannelExists() preserves the existing contract - it is
true between asyncOpen and onStopRequest - but the name is slightly off, as
the channel has already been open by the time we call asyncOpen. We will fix
this in a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D12419
--HG--
extra : moz-landing-system : lando
* Changes the format of the blocklist from a list of characters to a list of
character ranges. Binary search still works, and it is easier to include
large ranges of characters in the blocklist.
* Moves logic for handling the blocklist to IDNBlocklistUtils.h/.cpp
* Changes NS_EscapeURL to take a function that determines if a character
is blocked. This way the type of the array doesn't matter.
Differential Revision: https://phabricator.services.mozilla.com/D12210
--HG--
extra : moz-landing-system : lando
* Moves the value of the pref and also the fallback definition in nsTextToSubURI.cpp to a separate file.
* The file has better formatting, so we may follow its history more easily. Each range of consecutive values is defined on a separate line.
* Renames `blacklist` to `blocklist` for pref and variable names (for this individual pref. network.IDN.whitelist.* needs to be handled in a separate bug)
* Changes nsIDNService::mIDNBlocklist from being an nsString to sorted nsTArray<char16> and uses mozilla::BinarySearch() to check for characters.
Differential Revision: https://phabricator.services.mozilla.com/D12209
--HG--
extra : moz-landing-system : lando
A pipe is no longer used for the input stream, instead we use a string stream
which in most cases will be able to share the string data buffer rather than
copying it.
--HG--
extra : rebase_source : 592af1d2f55b7964d2b84c8e6f3def310557a866
WPT parses HTTP log and create a HAR file. To reduce the overhead of logging, this patch moves some logs that are used by WPT parser to level 1.
Differential Revision: https://phabricator.services.mozilla.com/D8986
--HG--
extra : moz-landing-system : lando
Now that h2 is pretty well stable, and we're fairly confident in our hpack table implementation, it's worth hiding this logging without some extra hoops, as it's just a lot of noise in logs.
Differential Revision: https://phabricator.services.mozilla.com/D11406
--HG--
extra : moz-landing-system : lando
https://tools.ietf.org/html/rfc8441
This uses our existing http/2 CONNECT infrastructure (modified) to
enable the new extended CONNECT form defined by 8441, and pretend for
the websocket's sake that an http/2 stream is actually a socket. From
the websocket's point of view, this is relatively non-invasive - a few
things have changed (http response code, absence of some headers) versus
http/1.1 websockets, but for the most part, the websocket code doesn't
care.
Differential Revision: https://phabricator.services.mozilla.com/D8016
--HG--
extra : moz-landing-system : lando
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
Unfortunately we can't test BEHAVIOR_REJECT using the AntiTracking framework,
because the AntiTracking callbacks are incompatible with it. (The tracking
callbacks expect to be able to unblock themselves, but under BEHAVIOR_REJECT,
that can't happen.)
Differential Revision: https://phabricator.services.mozilla.com/D10664
--HG--
extra : moz-landing-system : lando
Memory returned from PL_Base64Decode() is allocated with PR_MALLOC and
therefore needs to be freed with PR_FREE(), not free().
Differential Revision: https://phabricator.services.mozilla.com/D10745
--HG--
extra : amend_source : 820c1b987ed179e6f5ff51ec2ec91696588b6fa0
Unfortunately we can't test BEHAVIOR_REJECT using the AntiTracking framework,
because the AntiTracking callbacks are incompatible with it. (The tracking
callbacks expect to be able to unblock themselves, but under BEHAVIOR_REJECT,
that can't happen.)
Differential Revision: https://phabricator.services.mozilla.com/D10664
--HG--
extra : moz-landing-system : lando
For resolves that aren't associated with a hostrecord (like the initial
NS verification) there is no mRec pointer so set a blank originSuffix
then.
MozReview-Commit-ID: FuTP9qCm2Iu
Differential Revision: https://phabricator.services.mozilla.com/D10366
--HG--
extra : moz-landing-system : lando
When PR_Read/PR_White returns -1, we have to use ErrorAccordingToNSPR to get the error code. We need to close the transaction if the real error happens.
Differential Revision: https://phabricator.services.mozilla.com/D9674
--HG--
extra : moz-landing-system : lando
The inner window id here is used to log the error message to the right web console.
So, top level content window id should work properly if we can't get the inner window id directly from the request.
Differential Revision: https://phabricator.services.mozilla.com/D9497
--HG--
extra : moz-landing-system : lando
... when that NS check is used to check the "parent" domain of a
blacklisted host.
Previously, additional TRRblacklist entries due to this would always be
added with the originSuffix "" which was incorrect for all uses of other
suffxes.
MozReview-Commit-ID: EeorQuuRCRX
Differential Revision: https://phabricator.services.mozilla.com/D10192
--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 method is necessary because some threads might be stuck making blocking
calls. This means the thread is not processing any events, and we're unable
to safely terminate it. Our solution here is to leak the stuck threads
instead of waiting for them and potentially causing a shutdown hang.
Differential Revision: https://phabricator.services.mozilla.com/D9601
--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
Previously, we were sending INTERNAL_ERROR, but that's not really true. Firefox hasn't hit an error, we're just shutting down. It makes more sense to tell the peer we're not messed up, just going away nicely.
Depends on D8437
Differential Revision: https://phabricator.services.mozilla.com/D8439
--HG--
extra : moz-landing-system : lando
In certain cases (such as the case from bug 1050329, where a server claims to speak h2, but really doesn't), we will end up trying every connection to that server as h2 before falling back to http/1.1. Once we know a server is very badly behaved, it doesn't make sense to keep trying h2 (at least for the current browsing session). This adds an in-memory blacklist of origins & conninfos to not try h2 on, so we don't waste round trips trying h2, failing, and then dialing back with http/1.1 except for the first connection to an origin.
Depends on D8436
Differential Revision: https://phabricator.services.mozilla.com/D8437
--HG--
extra : moz-landing-system : lando
This is kind of like the previous patch (where we had a not-very-friendly user experience shutting down misbehaving h2 sessions), but in this case the server has proven to us that it can speak a minimum of h2, so we don't want to just fallback. Instead, when we send a GOAWAY frame because we have detected some error on the part of the server, if it's a top-level page load, we'll show an error page explaining that the server spoke bad http/2, and the site admin(s) need to be contacted. We already did this for INADEQUATE_SECURITY (which is its own special case still), but that didn't cover all the cases.
Differential Revision: https://phabricator.services.mozilla.com/D8436
--HG--
extra : moz-landing-system : lando
Previously, we would just let these fail. But, when a peer claims to speak h2 via ALPN, and then plainly doesn't speak h2 (by not doing the opening handshake properly), we should re-try any transactions dispatched to that session using http/1.1 only. No use in giving the user a horrible experience. We will also collect telemetry on how often we have sessions where this happens, so we can see how big of a problem this is (and thus if we need to do any kind of outreach).
Depends on D8432
Differential Revision: https://phabricator.services.mozilla.com/D8433
--HG--
extra : moz-landing-system : lando
Previously this was a macro, but in later patches in this series, I want to make the macro a bit smarter. There's no particular need to have it as a macro (and macros that return from functions are often considered no-nos), so this makes it a method on the session, instead.
Differential Revision: https://phabricator.services.mozilla.com/D8432
--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 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