This changes about:neterror to show a specific error page when the DNS failure
occurs for a TRR mode3 page load. This offers the user more information about
the failure, and some options.
This page will be further improved at a later stage when we add a better
DNS over HTTPS settings page.
The page is visible when the browser is using DNS over HTTPS without fallback
to native DNS. To achieve this the user sets `network.trr.mode` to `3` then
loads a page such as `http://nonexistant.test`.
If a top level load's channel returns NS_ERROR_UNKNOWN_HOST we look at
whether the page was indeed loaded with an effectiveTRRMode == TRRONLY
(some loads are excluded from using TRR).
When that is true, we present the error page allowing the user to retry,
exclude the domain from TRR, or open the settings page.
Note: This initial implementation will not work if the
`network.dns.disablePrefetch` pref is set to true. In that case nsHttpChannel
does not get an OnLookupComplete callback, so it doesn't have the
effectiveTRRMode and trrSkipReason. This will be fixed in bug 1805372.
Project plan: https://docs.google.com/document/d/12IGABt1eXI276qHduXXbVZqRFrhLN7Ad3gKEgxz81sE
Copy deck: https://docs.google.com/document/d/130UTox8bQbybjYIwvltR4qBg2hWjsGhuNUHypLwUAEQ
Depends on D164642
Differential Revision: https://phabricator.services.mozilla.com/D164347
Previosuly we'd only pass the `TRRService::ProviderKey()` into the content
process. But now we need the full domain for the error page in the content
process, so we now pass the full domain. The ChildDNSService now holds on
to the full domain, but calls into `TRRService` to update the key for
telemetry and returns that when necessary.
Depends on D164348
Differential Revision: https://phabricator.services.mozilla.com/D164642
In regexp-parser.cc, `MayContainStrings` switches on all the values of an enum class without a default case. V8 obviously isn't building with this as an error. Instead of sending a patch upstream every time this happens, it seems cleanest to treat this as a warning, not an error, in irregexp code.
Differential Revision: https://phabricator.services.mozilla.com/D165086
This file is auto-generated in V8. It only changes if `gen-regexp-special-case.cc` is modified, which happens very rarely, so instead of adding an extra step to our build process, I just update it manually when necessary.
Differential Revision: https://phabricator.services.mozilla.com/D165084
V8's equivalent of JitOptions were previously global variables, but they've been replaced with a system more similar to what we've got. We can rewrite the shim layer to use JitOptions directly.
Differential Revision: https://phabricator.services.mozilla.com/D165082
V8 added engine support for the new `/v` flag. We have bug 1713657 open for that. In the meantime, we can add just enough support to the shim to compile this code, even if we aren't using it yet.
Differential Revision: https://phabricator.services.mozilla.com/D165081
This worked well on Try, where I had some additional code to query the installed packages after running the uninstall -- that confirmed that Firefox was indeed uninstalled. There's still certain edge case where Firefox may remain -- mostly notably if the script crashes or otherwise exits in a way where the `uninstall` step is not run. These are probably uncommon enough not to worry about for now, though.
I'm not particularly happy that the `uninstall` step is being run and skipped for most platforms. I attempted to do this the "right" way by specifying either `actions` for these tests, or an additional command line arguments. With the former, adding `MOZHARNESS_ACTIONS` support to generic worker payloads resulted in a ton of unexpected changes to tests (eg: Android tests suddenly had explicit actions specified in a way that seemed it would break them). With the latter, I was unable to get `mozharness.extra-options` to support being keyed by anything without breaking one thing or the other (there's lots of transforms that append to it - and I couldn't find a place that I could resolve it being keyed by variant without busting one of them).
In the end, we do a bunch of things like this already, so I guess it's fine even if not ideal.
Differential Revision: https://phabricator.services.mozilla.com/D165394
I considered removing the `succeededOut` parameter, since none of the callers
handle failure differently, but then `serializeStencil()` and
`deserializeStencil()` would not be as symmetric. It would also remove the
ability in the future for the caller failure handling to be different.
Differential Revision: https://phabricator.services.mozilla.com/D165348
Negative frecency values have the defect of pushing down results in ranking
until the score is recalculated, thus recalculations must happen quickly, even
if they are expensive.
Since we plan to recalculate on idle and in chunks, it's better to preserve the
original frecency value until the recalculation can happen.
The initial frecency value when adding new entries to the database can still
be -1, it will be recalculated when either a bookmark or visit are added. That
should be the only acceptable negative value to indicate a new entry.
Frecency = 0 is still an indication the page's frecency should not be calculated
and may be associated with error pages or place: queries.
Original patch by Daisuke Akatsuka.
Differential Revision: https://phabricator.services.mozilla.com/D164929
Ensures that:
1) We never have stats report in a still-registered PC _and_ the stats for
closed PCs.
2) We never have a stats report disappear between when a PC is closed, and when
it deregisters.
3) If a stats report appears in WebrtcGlobalInformation as closed, a call to
ClearAllStats will ensure that this stats report does not reappear later
when the PC dereigsters.
Also simplifies things a bit.
Differential Revision: https://phabricator.services.mozilla.com/D162652
Also fix bugs where we would get duplicate ICE stats. This mostly mattered to
WebrtcGlobalInformation since RTCStatsReportInternal does not automatically
remove duplicate ids like RTCStatsReport (RTCStatsReport is maplike).
Differential Revision: https://phabricator.services.mozilla.com/D162322
My patch in bug 1805414 makes this fail in a way that's perma, and it
seems it is because we're not waiting for the actual value change to
happen.
Differential Revision: https://phabricator.services.mozilla.com/D165238
This should marginally improve content-process startup for processes that don't immediately
need to use the system font. No actual change in behavior, just taking the initialization
of the system-font faces out of the startup path.
Differential Revision: https://phabricator.services.mozilla.com/D165386
Valentin Gosu
Tom Schuster
Ryan VanderMeulen
Jim Blandy
alwu
fanie
Randell Jesup
Iain Ireland
Mozilla Releng Treescript
Cosmin Sabou
Iulian Moraru
Shane Hughes
Ben Hearsum
Bryan Thrall
Andreas Farre
Tooru Fujisawa
Cieara Meador
Thomas Wisniewski
Marco Bonardo
Byron Campen [:bwc]
ffxbld
Kershaw Chang
Sasaki Keiya
Emilio Cobos Álvarez
Jonathan Kew