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
"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
Nicholas Hurley
Ehsan Akhgari
Margareta Eliza Balazs
Daniel Stenberg
Valentin Gosu
Nils Ohlmeier [:drno]
Henri Sivonen
Thomas Wisniewski
Sylvestre Ledru
Andrea Marchesini
Diego Pino Garcia
Chris Peterson
Jonathan Kingston
Junior Hsu
Csoregi Natalia
Honza Bambas
Narcis Beleuzu
Michal Novotny
Andrew McCreight
Noemi Erli
Shane Caraveo
Daniel Varga
Gurzau Raul
Polly Shaw
Randell Jesup
arthur.iakab
Francois Marier
Dragana Damjanovic