Due to various reasons (network change, temporary network congestion, etc) it
may happen that we exceed the limit of TRR failures thus going into
CONFIRM_FAILED state and setting the timer for automatic retry.
When confirmation is not "skip" we want to reduce the amount of time as much
as possible - so if it's a transient reason for the failures, we should retry
as early as possible.
This patch reduces the initial timer to 125 ms (down from 1000 ms).
Exponential backoff is still in effect, so the only effect should be retrying
earlier. We also turn it into a pref, so it's easy to experiment with it to
find the perfect value.
Depends on D96822
Differential Revision: https://phabricator.services.mozilla.com/D96823
This threshold seems to be too low currently, leading to sometimes
dropping confirmation for unexpected network failures / changes.
Differential Revision: https://phabricator.services.mozilla.com/D96822
This will report when a telemetry even whenever we load an empty file via a
JAR channel. It will not catch situations where onStopRequest is called with
an error code, or when the listener of the channel does not consume the stream.
Differential Revision: https://phabricator.services.mozilla.com/D96412
On Nightly, for now. This allows websites to get the real viewport size.
The rounded size has caused problems in the past (see bug 1648298 / bug
1648265), and changing it would be ideal.
I told the CSSWG that we can experiment with this on Nightly to
alleviate (or prove) compat concerns, in which case we'd need to use a
different solution, see https://github.com/w3c/csswg-drafts/issues/5260.
Differential Revision: https://phabricator.services.mozilla.com/D96826
This will report when a telemetry even whenever we load an empty file via a
JAR channel. It will not catch situations where onStopRequest is called with
an error code, or when the listener of the channel does not consume the stream.
Differential Revision: https://phabricator.services.mozilla.com/D96412
We preserve their value, but by moving them to static prefs, we make
them embedded into the binary portion of the build, which means it's
allowed to differ between x86_64 and aarch64 in mac universal builds.
Differential Revision: https://phabricator.services.mozilla.com/D96522
Mostly for debugging / diagnosing purposes. This is easier than asking
people to try builds from try or building Firefox.
Differential Revision: https://phabricator.services.mozilla.com/D96648
This patch makes cranelift and ion exclusive of each other: enabling
cranelift on a platform will effectively disable Ion on that platform.
Specifically there's a change at the pref/switch level that does not
go terribly deep:
- the new about:config option is javascript.options.wasm_optimizingjit,
the old wasm_cranelift and wasm_ionjit are no more
- new values of X in --wasm-compiler=X in the js shell are 'optimizing'
and 'baseline+optimizing', the old values 'cranelift', 'ion',
'baseline+ion' and 'baseline+optimizing' are still accepted but only
when ion or cranelift is available
- we keep the separate prefs internally in the code for ion and cranelift
but if ENABLE_WASM_CRANELIFT is defined then we never set the ion
pref to true, and if it is not defined then we never set the cranelift
pref to true
The trickiest changes are in testWasm.cpp and in the JIT compiler option
processing in jsapi.cpp.
People who will suffer as a result of this are those who are working
on ports of cranelift to new platforms in Firefox. As of now we have
no such work going on.
In the longer term the exclusive-or situation can be alleviated by a
switch that lets cranelift override ion when cranelift is present and
the switch is on. Patches welcome.
Differential Revision: https://phabricator.services.mozilla.com/D96059
This was an old alternative fling implementation that could be opted
into with the pref apz.android.chrome_fling_physics.enabled=fase.
The pref is also removed.
Differential Revision: https://phabricator.services.mozilla.com/D96508
And use them to disable DOM_DELTA_LINES on Nightly builds, to see the
impact, since this is pretty hard to measure just with telemetry.
Differential Revision: https://phabricator.services.mozilla.com/D95388
We want to use dmabuf textures by default with VAAPI enabled. Remove the 'enabled' option as it's default now
and ship 'disabled' variant to force-disable it, mainly for debugging purposes.
Depends on D95994
Differential Revision: https://phabricator.services.mozilla.com/D95995
The other fling acceleration restrictions make it so that there is no need for
this additional restriction anymore.
Removing this restriction allows a fling to be accelerated even if the previous
fling has been "spinning" for a while (a second or more), provided that the page
is still moving fast enough.
This matches Chrome's behavior.
Differential Revision: https://phabricator.services.mozilla.com/D95472
This avoids unexpected acceleration after a "fling, fling, touch-pause-fling" sequence.
The touch start timestamp is captured when we go from NOTHING to TOUCHING,
and the pan start timestamp is captured when we go from TOUCHING to PANNING.
Differential Revision: https://phabricator.services.mozilla.com/D95470
We need to report when permission is added in order to wait it
explicitly. These will be put be hind a pref
'privacy.antitracking.testing' and should be only used for testing.
Differential Revision: https://phabricator.services.mozilla.com/D94979
We have ~10 months of CRLite telemetry-mode data in both Beta and Nightly, and about 2 months with data that has been kept up-to-date, and that telemetry agrees with our end-of-2019 experiment that CRLite should indeed speed up versus OCSP.
To confirm, we should enable the Enforce mode for Nightly users; that will stop collecting the CRLITE_FASTER_THAN_OCSP_MS and OCSP_FASTER_THAN_CRLITE_MS but should cause an improvement in SSL_TIME_UNTIL_READY as a weighting of the CRLITE_FASTER_THAN_OCSP_MS vs the percentage of cache-miss first page loads: we expect it'll mostly affect the outliers.
Differential Revision: https://phabricator.services.mozilla.com/D95814