This reverts commit 7e60482d8090a43e00957f3d6fc87f31d7ea65a1.
Of course it's not that simple. In Mozilla land they are also running
into issues but of a different variety and it was backed out there also.
The original state was inverted due to confusion due to a double
negative (not:no_error).
This validation should only be enabled on Windows (for now).
Future tracking and discussion in BZ 1862039
MozPromise::All sets up 'Then' lambdas on all sub-promises, each one
taking the resolve/reject object by value. Since this value will not be
used again in the lambda, it is safe to Move it, and from there
MozPromiseHolder::Resolve/Reject can also Move it again into the holder
storage, potentially saving two copies per Resolve/Reject. Also, once
all sub-promises have been resolved, the resolve-values can be Move'd
into the joining promise's Resolve function.
Web content should never read the clipboard; extensions have other APIs
they can use through XPCOM so do not need to go through
Navigator.Clipboard, removing the only reason why it would even be here.
I've been thinking about this issue, and ultimately it's just correcting a
mistake Mozilla made that no consumer of UXP's MailNews ever complained about
before, so I think it's reasonable to fix the default behavior first, and then
let others complain before I start worrying about prefs or ifdefs. One thing
at a time.
GNU readelf isn't available as consistently as I assumed across SunOS,
and it can be named different things on different illumos distros (some call
it readelf, others call it greadelf, etc), so it's safer to use elfdump.
This is a fairly easy fix, just kind of annoying.
Generating OS-appropriate mapfiles from a provided SYMBOL_FILE is
apparently required to work with newer ffvpx. Nothing else in our
codebase actually seemed to require it. Also seems to reduce the amount
of console spam I see relating to symbol visibility during the build
process, and I think it even makes libxul.so link a bit faster.
Signed-off-by: athenian200 <athenian200@outlook.com>
This ensures we don't scale the underlying size of the layer beyond what
is close to the current display size. When box shadows get much larger
than this, they start taking so much time to render that successive
frames grow in scale too fast for any inter-frame reuse to be possible.
With this, we avoid that and no longer get crushed by re-rendering
gigantic box shadows every single frame.
See BZ 1383825
A second template parameter 'F' was previously added to SizeTyped, but
was not correspondingly added to the argument passed for the 'Sub'
parameter of BaseSize.
There's considerable cost associated with creating HWA draw targets
which would negate and regress the performance won by it if used for
too small targets (like small spans of text).
This only uses HWA if >= 8K SurfaceAllocationSize to balance HWA draw
target cost with box blur cost.
Only blur one quadrant of a box-shadow and mirror it to the other quadrants.
This applies only if the corners are symmetrical (square corners or equal
corner radii) otherwise we'll fall back to the old method.
