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
* Blur before focus to reset timer for filtering <select>
* Wait for field to get focus before sending keys to it.
* Compare unpadded strings
Differential Revision: https://phabricator.services.mozilla.com/D6338
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.
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
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
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
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
Jonathan Watt
arthur.iakab
Margareta Eliza Balazs
Jan de Mooij
Andrea Marchesini
Gurzau Raul
Andreea Pavel
Jared Wein
Jeff Muizelaar
Mike Hommey
Andrew Osmond
Olli Pettay
Dana Keeler
Kartikaya Gupta
Kris Maglione
Tim Nguyen
Nick Thomas
Matt Woodrow
Nicolas Ouellet-Payeur
Iain Ireland
Thomas P.
Luke Wagner
Calixte Denizet
Connor Sheehan
Ursula Sarracini
Miko Mynttinen