We need this for the next patch because we have a JSOp instead of a pc when
generating the interpreter. (In general it's nicer for functions to take a JSOp
instead of a PC because it can be used in strictly more contexts.)
Differential Revision: https://phabricator.services.mozilla.com/D38864
--HG--
extra : moz-landing-system : lando
The old code happened to work for Baseline JIT bailouts because the JIT ignores
the return value slot for noScriptRval scripts, but when bailing out to the
interpreter we would have an optimized-out MagicValue in the return value slot
and get confused.
Differential Revision: https://phabricator.services.mozilla.com/D38863
--HG--
extra : moz-landing-system : lando
The old code happened to work but didn't really make sense and I ran into some assertion
failures with other changes. Later patches will clean this up more.
Differential Revision: https://phabricator.services.mozilla.com/D38862
--HG--
extra : moz-landing-system : lando
We now always set the frame's environment chain to a non-null value and have
an explicit isPrologueBailout flag instead of relying on envChain == nullptr.
Differential Revision: https://phabricator.services.mozilla.com/D38861
--HG--
extra : moz-landing-system : lando
When we resumeAfter a JOF_TYPESET op, we had code to enter the type monitor
chain for the bailing op, passing it the top stack value. It's simpler to do
this monitoring in C++ in FinishBailoutToBaseline and then treat it as a regular
resumeAfter bailout.
The code for this will be simplified more later in the stack.
Differential Revision: https://phabricator.services.mozilla.com/D38860
--HG--
extra : moz-landing-system : lando
We're hitting double imprecision here.
Example: Given 86.68392200000000 and 86.67999999999999 we want to see
if they're equal with two significant digits. (They are, they're 86.68)
However, when we reduce them, 86.68 (which is represented as an epislon lower)
gets reduced to 86.66 and they no longer match. We disable unconditional clamping
on these tests to confirm they behave the way they shoud... excepting the clamping
which may introduce imprecision.
Differential Revision: https://phabricator.services.mozilla.com/D38812
--HG--
extra : moz-landing-system : lando
I believe these intermittents are caused by double imprecision. When unconditional clamping is enabled
it gets multiplied out and causes animation.currentTime to occasionally go to 50000.02 which causes
the test to fail. We can reduce the precision back down to ignore that. We do so using some WPT
overrides.
Differential Revision: https://phabricator.services.mozilla.com/D38810
--HG--
extra : moz-landing-system : lando
This has to do with double imprecision. The test originally had toPrecision(6) to
account for this imprecision. It'd round up 499.9999 into 500. When we send
double(500) (which is an epsilon below 500) into ReduceTimePrecision we wind up
coming out with 499.98. By reducing our precision requirement in this test
we can handle that and round 499.98 back up to 500
Differential Revision: https://phabricator.services.mozilla.com/D38809
--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
Use counters are collected in release as of bug 1477433. Per bug 1204994, use counters need to be interpreted relative to CONTENT_DOCUMENTS_DESTROYED and TOP_LEVEL_CONTENT_DOCUMENTS_DESTROYED, so these need to be collected in release, as well.
Also cleans up probe definitions and removes from whitelists.
Differential Revision: https://phabricator.services.mozilla.com/D39726
--HG--
extra : moz-landing-system : lando
This code now became obsolete and broken with the autocomplete popup being anchored to the textbox instead of the textbox inner input.
Differential Revision: https://phabricator.services.mozilla.com/D39794
--HG--
extra : moz-landing-system : lando
Allow the swizzle to be configurable with a texture binding. This is still experimental and needs to be tested well on all platforms.
Basic approach is the following:
- WR device figures out how it can use BGRA and makes the texture cache format configurable at run-time. It tries to make the uploads to the shared texture cache pages to be done without any driver conversions, and without extra memory allocated.
- it also reports the preferred input format for the images, which may be different from the texture cache format
- if WR texture cache is asked to allocate a shared texture with a different (swizzled) format from the preferred, it associates the cache entry with a swizzle
- the swizzle becomes a part of the `SourceTexture`, which affects batch splitting
- when a texture reaches binding by GL device, it checks whether the current swizzle on this texture doesn't match the given one, and configures the texture sampling accordingly
- we can't use blits with swizzling, so when that needs to happen we use `cs_copy` path, which is now mostly rewritten
The idea is that Gecko would ask WR for the preferred format and configure its image decoding to produce image data that doesn't require any swizzling.
The PR changes existing texture upload (and batching) paths. On Linux, if texture storage is available, we now use it and provide the data as RGBA, assuming no conversion by the driver. The swizzling kicks in when we sample this data in the shader. On Windows/Angle we use BGRA as an internal format for texture cache and expect Gecko to provide BGRA data, this should be unchanged.
Differential Revision: https://phabricator.services.mozilla.com/D21965
--HG--
extra : moz-landing-system : lando
We're hitting double imprecision here.
Example: Given 86.68392200000000 and 86.67999999999999 we want to see
if they're equal with two significant digits. (They are, they're 86.68)
However, when we reduce them, 86.68 (which is represented as an epislon lower)
gets reduced to 86.66 and they no longer match. We disable unconditional clamping
on these tests to confirm they behave the way they shoud... excepting the clamping
which may introduce imprecision.
Differential Revision: https://phabricator.services.mozilla.com/D38812
--HG--
extra : moz-landing-system : lando
I believe these intermittents are caused by double imprecision. When unconditional clamping is enabled
it gets multiplied out and causes animation.currentTime to occasionally go to 50000.02 which causes
the test to fail. We can reduce the precision back down to ignore that. We do so using some WPT
overrides.
Differential Revision: https://phabricator.services.mozilla.com/D38810
--HG--
extra : moz-landing-system : lando
This has to do with double imprecision. The test originally had toPrecision(6) to
account for this imprecision. It'd round up 499.9999 into 500. When we send
double(500) (which is an epsilon below 500) into ReduceTimePrecision we wind up
coming out with 499.98. By reducing our precision requirement in this test
we can handle that and round 499.98 back up to 500
Differential Revision: https://phabricator.services.mozilla.com/D38809
--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
Gabriel Luong
Jan de Mooij
Tom Ritter
championshuttler
Neil Bleasdale
Jared Wein
Tomislav Jovanovic
Simon Giesecke
Carolina
Alex Catarineu
Tim D. Smith
Dão Gottwald
Tim Nguyen
Patrick Brosset
Julian Descottes
Dzmitry Malyshau
Andreea Pavel
Staś Małolepszy