When switching to async, it is important to catch exception or register a rejection handler
so that errors keep being logged.
So in this patch I'm catching exception in a couple of important codepath.
Depends On D4541
Differential Revision: https://phabricator.services.mozilla.com/D4542
--HG--
extra : moz-landing-system : lando
Fetching any target is now asynchronous. But RDM setup/destroy codepath is very fragile
and introduce many low level exception when trying to restore the original browser element
if any timing changes.
So this patch prevents trying to fetch the target object if a toolbox isn't already opened.
The target object is being used only for Telemetry purpose for now.
Depends On D4538
Differential Revision: https://phabricator.services.mozilla.com/D4540
--HG--
extra : moz-landing-system : lando
We are not passing a tab here. It only works by chance!
Depends On D4535
Differential Revision: https://phabricator.services.mozilla.com/D4536
--HG--
extra : moz-landing-system : lando
We want to get rid of JS_GetCompartmentPrincipals. The origin stored in CompartmentPrivate does not account for document.domain changes because that's a per-realm thing.
Fortunately we should not have waivers in any cases that involve document.domain.
Differential Revision: https://phabricator.services.mozilla.com/D6035
--HG--
extra : moz-landing-system : lando
In the grouper code we don't currently support active masks so
this makes sure that we handle 3d transforms that are inactive.
Differential Revision: https://phabricator.services.mozilla.com/D6459
--HG--
extra : moz-landing-system : lando
Doing so changes the size of the compressed toolchain archive from ~280M
to ~120M, and the decompressed size from ~1500M to ~675M. This will
reduce the overhead of decompression during builds.
As we ship llvm-symbolizer as part of ASan builds, we do need it to
still statically link against LLVM, which we do with a small patch.
With LLVM as a shared library, libLTO, which is used by cctools-port for
the linker, is dynamically linked to LLVM, and the cctools-port
configure script fails to link against libLTO. So we add a -rpath-link
to make it find the LLVM library. This happens to force a rebuild of
cctools-port, but for future cases where we might need a rebuild because
of some clang changes, we add a comment to ease the process, and avoid
a newer cctools-port taking the cache spot of an older one.
Ideally, mac cctools-port would need something similar, but it needs a
mac libLTO.dylib, which is not there anyways (and the mac cctools-port
thus already didn't support LTO).
Also, with LLVM built as a shared library, all its symbols are exported
with a LLVM_x.y version. Combined with -static-libstdc++ that is used
during the clang build, this causes problems (see
https://bugzilla.mozilla.org/show_bug.cgi?id=1492037#c7). But it turns
out things have evolved since -static-libstdc++ has been added to the
clang build script, and things work without now, so remove it (as well
as -static-libgcc).
Differential Revision: https://phabricator.services.mozilla.com/D6117
Pages that are whitelisted for displaying on about:about can be
autocompleted in the URL bar.
MozReview-Commit-ID: BYhWUImyiJH
Differential Revision: https://phabricator.services.mozilla.com/D3072
--HG--
extra : moz-landing-system : lando
If FLAG_HIGH_QUALITY_SCALING is used, we should use
SurfaceCache::LookupBestMatch just like how it is done in RasterImage.
This may provide an alternative size at which we should rasterize the
SVG instead of the requested size. Since SurfaceCache imposes a maximum
size for which it will permit rasterized SVGs, we should also bypass the
cache entirely if we are well above that and simply draw directly to the
draw target in such cases.
With WebRender, it is somewhat more complicated. We will now return
NOT_SUPPORTED if the size is too big, and this should trigger fallback
to blob images. This should only produce drawing commands for the
relevant region and save us the high cost of rasterized a very large
surface on the main thread, which at the same time, looking as crisp as
a user would expect.
There is one main difference between raster images and vector images
with respect to factor of 2 scaling. Vector images may be scaled
infinitely and so we need to extend factor of 2 scaling to permit
growing instead of just shrinking. Also, we don't want to scale
infinitely, so we should configure a maximum size limit. This size limit
will apply even outside of factor of 2 scaling, and so the caller
(VectorImage) will need to be careful to take this into account.
The site identity security indicator machinery treats connections where the TLS
handshake failed as insecure (also referred to as "unknown identity"). Before
bug 1468222, such cases were easily detectable as the SSLStatus field of the
relevant nsITransportSecurityInfo would be null. When we merged nsISSLStatus
into nsITransportSecurityInfo, we didn't take this differentiation into account.
This patch brings back the prior behavior by checking if the securityInfo's
securityState indicates that the handshake failed (i.e. it is
STATE_IS_INSECURE).
Differential Revision: https://phabricator.services.mozilla.com/D6316
--HG--
extra : moz-landing-system : lando
Doing so changes the size of the compressed toolchain archive from ~280M
to ~120M, and the decompressed size from ~1500M to ~675M. This will
reduce the overhead of decompression during builds.
As we ship llvm-symbolizer as part of ASan builds, we do need it to
still statically link against LLVM, which we do with a small patch.
With LLVM as a shared library, libLTO, which is used by cctools-port for
the linker, is dynamically linked to LLVM, and the cctools-port
configure script fails to link against libLTO. So we add a -rpath-link
to make it find the LLVM library. This happens to force a rebuild of
cctools-port, but for future cases where we might need a rebuild because
of some clang changes, we add a comment to ease the process, and avoid
a newer cctools-port taking the cache spot of an older one.
Ideally, mac cctools-port would need something similar, but it needs a
mac libLTO.dylib, which is not there anyways (and the mac cctools-port
thus already didn't support LTO).
Also, with LLVM built as a shared library, all its symbols are exported
with a LLVM_x.y version. Combined with -static-libstdc++ that is used
during the clang build, this causes problems (see
https://bugzilla.mozilla.org/show_bug.cgi?id=1492037#c7). But it turns
out things have evolved since -static-libstdc++ has been added to the
clang build script, and things work without now, so remove it (as well
as -static-libgcc).
Differential Revision: https://phabricator.services.mozilla.com/D6117
If FLAG_HIGH_QUALITY_SCALING is used, we should use
SurfaceCache::LookupBestMatch just like how it is done in RasterImage.
This may provide an alternative size at which we should rasterize the
SVG instead of the requested size. Since SurfaceCache imposes a maximum
size for which it will permit rasterized SVGs, we should also bypass the
cache entirely if we are well above that and simply draw directly to the
draw target in such cases.
With WebRender, it is somewhat more complicated. We will now return
NOT_SUPPORTED if the size is too big, and this should trigger fallback
to blob images. This should only produce drawing commands for the
relevant region and save us the high cost of rasterized a very large
surface on the main thread, which at the same time, looking as crisp as
a user would expect.
There is one main difference between raster images and vector images
with respect to factor of 2 scaling. Vector images may be scaled
infinitely and so we need to extend factor of 2 scaling to permit
growing instead of just shrinking. Also, we don't want to scale
infinitely, so we should configure a maximum size limit. This size limit
will apply even outside of factor of 2 scaling, and so the caller
(VectorImage) will need to be careful to take this into account.
There are cases when we asynchronously handle tab events, and therefore try to
attach an ID to a tab after it's already been removed. In practice, this will
typically only affect tests, since it requires the tab to be removed
immediately after a related event is dispatched, but in those cases, it causes
a leak, since there's no way for the tab to be removed after the map after
that point.
We should ideally get rid of those weird async hacks, but either way, we
should ensure that we never add a tab to the map after it's already been
removed. This patch does that.
Differential Revision: https://phabricator.services.mozilla.com/D6435
--HG--
extra : rebase_source : 9b6bea993f6261596f2c6283d6569632d395d68b
Function names in gcda are just here to check that they match the ones we've in gcno: this is an extra check since it already exists a function checksum for this purpose.
So the size of gcda and the time to generate them will decrease.
Differential Revision: https://phabricator.services.mozilla.com/D6413
--HG--
extra : moz-landing-system : lando
This commit updates submit_telemetry_data.py to send data
to the Telemetry pipeline. The script assumes the presence
of a "telemetry" directory within the statedir, and an
"outgoing" directory within the "telemetry" directory (otherwise
there is no data to submit). The script will create a
"submitted" directory and "telemetry.log" file if absent,
making the assumption that this is the first build telemetry
submission for that user. UUID values for submitted data points
are seeded from the filename, without the ".json" suffix.
Differential Revision: https://phabricator.services.mozilla.com/D5687
--HG--
extra : moz-landing-system : lando
This patch prevents Fennec/GeckoView crash reporters from sending the large,
useless StackTraces field when submitting a report. I've also taken the
liberty of removing an obsolete crash annotate that was being added to
Fennec's reports.
Differential Revision: https://phabricator.services.mozilla.com/D6389
--HG--
extra : moz-landing-system : lando
In the button case we have a ::-moz-button-content pseudo-element, but this is
also an issue for tables and such.
These are supposed to be implementation details, so avoid looking at them for
preserve-3d.
I don't know how I didn't think of this on the regressing bug.
Differential Revision: https://phabricator.services.mozilla.com/D6131
This removes the info messages and adds the packet type to the error messages.
Differential Revision: https://phabricator.services.mozilla.com/D6392
--HG--
extra : moz-landing-system : lando
