This asserts that the embedder is always set soon enough that we don't run into
the situation which caused the null deref fixed by bug 1565489.
Differential Revision: https://phabricator.services.mozilla.com/D39187
--HG--
extra : moz-landing-system : lando
This refactors things to run until the animation is unthrottled. It confirms
the proper amount of time has passed; and then awaits another styling to ensure
that markers.length = 0 (unless it took very long (over 200ms) that it should
be 1.
Differential Revision: https://phabricator.services.mozilla.com/D38808
--HG--
extra : moz-landing-system : lando
We fix this by clamping the requestAnimationFrame timestamp in the test before comparing it.
We don't clamp the requestAnimationFrame timestamp normally because it would be meaningless:
rAF fires on a regular frequency and someone perfoming a fine-grained timing attack will be
able to determine the timestamp from when it fires.
We need to use parseFloat to knock off any extra epislon we gain.
This shouldn't cause any major blow-ups because timelines are disabled in release and beta,
so at least any potential fallout would be constrained.
Differential Revision: https://phabricator.services.mozilla.com/D38807
--HG--
extra : moz-landing-system : lando
We unconditionally clamp all times to 20us and not just performance.now()
This will consistently apply a 'safe' minimal clamping (it's not safe but
I guess it's safer than ns-level precision) to all timestamps, and remove
intermittents that are caused by comparing a clamped performance.now() to
an unclamped [something else].
Differential Revision: https://phabricator.services.mozilla.com/D38806
--HG--
extra : moz-landing-system : lando
EncodeString and EncodeBinary already use a common backend EncodeAsString,
the same should be done in decoding, as the encoding of a binary is
a special case of the encoding of a string.
Differential Revision: https://phabricator.services.mozilla.com/D38076
--HG--
extra : moz-landing-system : lando
The comment referenced the former 3 prefix used for strings, but this is
no longer correct for strings (which now use a 0x30) prefix, and the
function has been generalized to also work for binaries, and got
a parameter aType specifying the prefix. Updated the comment accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D37850
--HG--
extra : moz-landing-system : lando
When privacy.spoof_english = 2, we should hide the user's
locale in content. So we use en-US default strings for HTML
form elements, such as a Submit button.
We also force GetLocalizedEllipsis() to always return the
ellipsis used by en-US.
Differential Revision: https://phabricator.services.mozilla.com/D35815
--HG--
extra : moz-landing-system : lando
This refactors things to run until the animation is unthrottled. It confirms
the proper amount of time has passed; and then awaits another styling to ensure
that markers.length = 0 (unless it took very long (over 200ms) that it should
be 1.
Differential Revision: https://phabricator.services.mozilla.com/D38808
--HG--
extra : moz-landing-system : lando
We fix this by clamping the requestAnimationFrame timestamp in the test before comparing it.
We don't clamp the requestAnimationFrame timestamp normally because it would be meaningless:
rAF fires on a regular frequency and someone perfoming a fine-grained timing attack will be
able to determine the timestamp from when it fires.
We need to use parseFloat to knock off any extra epislon we gain.
This shouldn't cause any major blow-ups because timelines are disabled in release and beta,
so at least any potential fallout would be constrained.
Differential Revision: https://phabricator.services.mozilla.com/D38807
--HG--
extra : moz-landing-system : lando
We unconditionally clamp all times to 20us and not just performance.now()
This will consistently apply a 'safe' minimal clamping (it's not safe but
I guess it's safer than ns-level precision) to all timestamps, and remove
intermittents that are caused by comparing a clamped performance.now() to
an unclamped [something else].
Differential Revision: https://phabricator.services.mozilla.com/D38806
--HG--
extra : moz-landing-system : lando
EncodeString and EncodeBinary already use a common backend EncodeAsString,
the same should be done in decoding, as the encoding of a binary is
a special case of the encoding of a string.
Differential Revision: https://phabricator.services.mozilla.com/D38076
--HG--
extra : moz-landing-system : lando
The comment referenced the former 3 prefix used for strings, but this is
no longer correct for strings (which now use a 0x30) prefix, and the
function has been generalized to also work for binaries, and got
a parameter aType specifying the prefix. Updated the comment accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D37850
--HG--
extra : moz-landing-system : lando
They're infallible in practice and always `NS_OK`. (This stems from
`AddVarCacheNoAssignment()` always returning `NS_OK`.)
As a result, the commit removes lots of unnecessary checks.
Differential Revision: https://phabricator.services.mozilla.com/D39804
--HG--
extra : moz-landing-system : lando
This is an example refcounted actor which was easy enough to port over as an
initial test. More can be ported in the future, potentially alongside removing
`mIPCOpen`.
Differential Revision: https://phabricator.services.mozilla.com/D39503
--HG--
extra : moz-landing-system : lando
When we reload the document the destruction of the old document triggers a discard request for the image. If timing is right we haven't locked the image in the new document yet so it discards.
We call LoadImage on the image, it returns the existing entry from the image cache, but it needs to validate. When it validates we send out all the progress in the progress tracker already. This includes frame complete and decode complete even though we have no decoded surfaces for this image right now.
The RequestDecodeForSize call in nsImageLoadingContent::MaybeResolveDecodePromises triggers a decode. When the decode finishes we send a frame update notification but we never send frame complete or decode complete because those are permanent once they happen.
Differential Revision: https://phabricator.services.mozilla.com/D39585
--HG--
extra : moz-landing-system : lando
Converts dom.timeout.enable_budget_timer_throttling from varcache pref to static pref, removes entry from all.js, adds entry to StaticPrefList.yaml. Uses the all.js value and not the value declared in TimeoutManager.cpp. Since this removes the last varcache pref from TimeoutManager::Initialize(), I also removed the Initialize() function and its call in nsGlobalWindowInner.
Differential Revision: https://phabricator.services.mozilla.com/D39455
--HG--
extra : moz-landing-system : lando
Converts dom.timeout.budget_throttling_max_delay varcache pref to static pref, removes entry from all.js, and adds entry to StaticPrefList.yaml
Differential Revision: https://phabricator.services.mozilla.com/D39451
--HG--
extra : moz-landing-system : lando