When building the GPUBuffer during the prepare pass, we want to be
able to refer to the UV rect (and other information) about images
and render tasks. However, we don't know this information until
after the resource cache block that occurs after prepare (waiting
for blob / glyph worker threads to complete).
Previously, we would defer these queries until batching and then
reference these via a GPU cache address in the instances, which
is complicated and inefficient (making instances larger than they
need to be).
With this change, GPUBuffer supports recording "patch" locations in
the buffer that UV rects should be added. After the render task
graph is built, the GPUBuffer can resolve and patch those locations,
meaning that batching is much simpler (and reducing the number of
indirect fetches required in vertex shaders).
Differential Revision: https://phabricator.services.mozilla.com/D159236
This revision modifies aspects of AccAttributes to make them a bit easier to
work with from a developer perspective. One big win here is the removal of
SFINAE logic that prunes the overload set when resolving calls to SetAttribute.
That logic, plus the other overloads of SetAttribute, have been translated
fairly directly into if constexpr blocks in a single SetAttribute
implementation. The upshot of this is that we can now explicitly disallow
people, at compile time, from accidentally making string copies when passing
strings to SetAttribute, with a nice error message! This revision also enables
us to use AccAttributes in a read-only fashion, particularly in range-based for
loops. This revision accomplishes that by adding const wherever is reasonable.
Next, this revision also removes some redundant special member function
definitions (deletions). My hope is that these changes will generally make
AccAttributes easier to use as safely as possible. Finally, this revision
updates a couple places where we use AccAttributes in a read-only way such
that they use the new const mechanisms.
Differential Revision: https://phabricator.services.mozilla.com/D158995
Now that Python's stdlib `venv` is used, `virtualenv` is no longer
needed.
Since mozharness depends on the wheels for `setuptools` and `pip`, and
they were vendored within `virtualenv` we must move them somewhere else.
I've chosen to add `third_party/python/venv/wheels` to hold those wheels
now that `virtualenv` is no longer there.
Depends on D145786
Differential Revision: https://phabricator.services.mozilla.com/D145787
The 'pip' and 'setuptools' that are bundled with 'venv' are not
consistent across python version and platforms. As such, we must
explicitly install a version of each that works with our codebase.
To achieve this, we simply create the venv using '--without-pip'
then 'pip install' both 'pip' and 'setuptools' using the wheels we have
'vendored' inside 'virtualenv'. There's no way to install a specific
version of 'pip' on venv creation, so it's faster to skip installing the
old version of 'pip' then, and install specific version we want right
afterwards.
We don't want to use the venv '--upgrade` feature to upgrade 'pip',
since that will tie us to pypi, and will fail if pypi is down for
whatever reason.
Depends on D144872
Differential Revision: https://phabricator.services.mozilla.com/D145786
Brew's Python 3.10 causes `virtualenv==20.7.2` to produce a wonky folder
structure (`$venv/opt/homebrew/lib/python3.10/site-packages`?).
This is likely fixed with newer `virtualenv`, but the simpler workaround
here is to use `venv` instead now that Python 3 is always used.
Adds `python3-venv` to docker image so that tests and debian-based tasks
can leverage it.
Differential Revision: https://phabricator.services.mozilla.com/D144872
Now that all fields and methods in WebAccessibleResource have been made
threadsafe, we can make the type itself be threadsafe.
Differential Revision: https://phabricator.services.mozilla.com/D158885
In order to make WebAccessibleResource threadsafe, as well as other places, it
needs to be possible to look up a `WebExtensionPolicyCore` from any thread.
This is handled by using a static method on the ExtensionPolicyService for this
task, and keeping a seperate mutex-guarded static table under the hood.
Theoretically the table within `ExtensionPolicyService()` could also be
removed, however I held off on doing that in case it would have a negative
performance impact to take extra locks and follow extra pointers.
Differential Revision: https://phabricator.services.mozilla.com/D158884
Similar to MatchGlob, this is fairly straightforward, but is complicated
slightly by `MatchPatternSet`, which allows being destructured into the
contained `MatchPattern` instances in a `[Constant]` method. To handle this a
cache is added for the wrappers in the cycle-collected `MatchPatternSet`.
Differential Revision: https://phabricator.services.mozilla.com/D158883
The mutator methods were never used, so were easy to remove, allowing the type
to be made threadsafe. The main potential for performance regression is that
the string based Contains method now uses `NS_Atomize` instead of
`NS_AtomizeMainThread`, however this is only called in once place
(WebExtensionPolicy::HasPermission). If it turns out to be an issue, we can
move the atomization into the caller to keep it using `NS_AtomizeMainThread`.
Differential Revision: https://phabricator.services.mozilla.com/D158880
This threadsafe core type also acts as a weak reference to the main-thread
WebExtensionPolicy when needed. This will be used when information about a
WebExtension is needed to be accessible off-main-thread in the future.
Differential Revision: https://phabricator.services.mozilla.com/D158879
In debug mode, the compile for some regular expressions is much slower with the
regex crate than it was with the JS engine, likely due to the regex's crate
heavy reliance on inlining and other llvm optimizations. Subsequent runs are
much faster, as they do not need to optimize and build the DFA.
Differential Revision: https://phabricator.services.mozilla.com/D158878
This also involves making MatchGlob operate on UTF8String instead of DOMString,
as the rust `regex` crate operates on utf-8 strings. This should have no
functional impact on callers.
Differential Revision: https://phabricator.services.mozilla.com/D158877
The `RustRegex` wrapper is built on the official `rure` ffi bindings for the
`regex` crate, which was added in previous parts. The `regex-ffi` crate will be
removed in the next part.
Differential Revision: https://phabricator.services.mozilla.com/D158875
This will make customizing flags on the regex type less error-prone, as passing
a flag (e.g. `RustRegex::FLAG_CASEI`) will not implicitly disable the default
`UNICODE` flag.
Names and comments were taken from the original `RegexBuilder` type in the
`regex` crate which this type is inspired by, and the type was changed to be
cheaply copyable and support method chaining, so that it can be used more
ergonomically.
Differential Revision: https://phabricator.services.mozilla.com/D159083
This makes the API more ergonomic to use from our c++ code, managing things
like lifecycles automatically.
Documentation comments are copied from the `rure.h` header, and modified
slightly to reflect the C++ types.
Differential Revision: https://phabricator.services.mozilla.com/D158874
While we already have an in-tree `regex-ffi` crate which provides basic
access to regex functionality for use in FormAutofillNative, the `regex`
crate itself provides and maintains its own c api as the `rure` crate.
This patch vendors in `rure` to allow us to use the more-fully-featured
official ffi.
Differential Revision: https://phabricator.services.mozilla.com/D158873
NextSibling uses IndexInParent, which is currently slow for RemoteAccessible.
Even if IndexInParent were faster, we're iterating all children here, so doing it this way is more efficient regardless.
This results in a significant performance improvement (> 25x) with NVDA when thousands of HTML select options are shown.
Differential Revision: https://phabricator.services.mozilla.com/D159149
We first retrieve accessible bounds and then pass them to a content task to compare against content layout bounds. We are not guaranteed to have the cache in sync in that manner, most tests will wait for a content rAF but that is not sufficient for the parent cache's state.
Instead we need to pull the content layout bounds (since those are guaranteed to be in sync via rAF) into parent and then wait for the a11y cache to catch up.
Differential Revision: https://phabricator.services.mozilla.com/D159080
They haven't been scriptable in years, so there's no need for them to go
through XPIDL or for the methods to be virtual.
Differential Revision: https://phabricator.services.mozilla.com/D158081
Some more of these tests could probably be removed completely, but they still
leave some vestigial opaque COW tests that might still be worse something,
even though they should be completely redundant.
Differential Revision: https://phabricator.services.mozilla.com/D158997
They haven't been scriptable in years, so there's no need for them to go
through XPIDL or for the methods to be virtual.
Differential Revision: https://phabricator.services.mozilla.com/D158081
Adds the CERT_REVOCATION_MECHANISMS histogram with bins "CRLite", "Stapled OCSP", "Cached OCSP", "OCSP", "OneCRL", and "Short Validity" to gauge how often we use each certificate revocation checking mechanisms. The Short Validity bin counts cases where a revocation check was not performed because the certificate had a short validity period. The other bin names are self-explanatory. We may use more than one mechanism per certificate, so we may accumulate to more than one bin per certificate.
Differential Revision: https://phabricator.services.mozilla.com/D158975
Chris Peterson
Glenn Watson
Mike Hommey
Jan Varga
Tooru Fujisawa
Cristian Tuns
Yury Delendik
Nathan LaPre
ahochheiden
Nika Layzell
Dana Keeler
James Teh
Dan Robertson
Amy Churchwell
Eitan Isaacson
Mark Hammond
Kris Maglione
Emily McMinn
Kris Maglione
Emilio Cobos Álvarez
John Schanck
Barret Rennie