Add some tests for handling of uncaught exceptions, and tests for value
and exception propagation.
MozReview-Commit-ID: 4sEakRr1lLo
--HG--
extra : rebase_source : abdd25a09b56e70f45e4a7a7221498faca04c84d
Use wl_keyboard_listener and keymap event to get key mapping on Wayland. Weston simple-im.c example
is used as a reference implementation and actual key modifiers are derived from Wayland/GDK code from
gdkkeys-wayland.c.
MozReview-Commit-ID: 9fMwCvxkYy0
--HG--
extra : rebase_source : 21212cadfa7b1e8bacec2d6fb6970d2aaba7b3f6
The new version of breakpad imported in bug 1309172 doesn't demangle
rust symbols at all, contrary to before, where it tried to C++ demangle
them, which worked for many, although far from all. It however has
rust-demangle support as long as it's linked against a copy of the
rust-demangle-capi crate from https://github.com/luser/rust-demangle-capi/
This imports the code from the rust-demangle-capi crate but because of
some build system complications it's not taken as-is:
- it uses rusty-cheddar, which is deprecated, to generate a C header.
- rusty-cheddar depends on syntex_syntax, which now fails to build.
- rust-demangle-capi has crate-type staticlib, which can't be used
as a dependency in a Cargo.toml. For that reason, we can't create
a fake crate that depends on it to have it vendored.
Overall, it's only a few lines of rust, and the C header can be written
manually, so this is what we do here. The created crate is named in a way
specific to dump_syms.
The build system doesn't know how to figure out what system libraries
are required to link rust static libraries, although the rust compiler
has /some/ support to get the information, so we handle that manually.
--HG--
extra : rebase_source : 9f5a9bfe2148d3040e11c7121a88e85a7f2d5c53
This is assuming we want to pref off for 62 and pref on again for 63, simply delaying the feature by one release.
MozReview-Commit-ID: 7Q4uD7QJDFc
--HG--
extra : rebase_source : 5839daaac17384fdca8969e750af2bb76b6403fb
We need to call ReadTests because otherwise we wouldn't recompute `g.urls`.
Similarly, we don't want to throw when there are no remaining reftests, since we
handle that case properly.
Differential Revision: https://phabricator.services.mozilla.com/D2069
--HG--
extra : moz-landing-system : lando
When the pending animation having no target element sets a new effect having
a target element associated with a document, PendingAnimationTracker has to
start tracking the animation regardless of mPendingReadyTime.
MozReview-Commit-ID: DxmbXtLhjCT
--HG--
extra : rebase_source : 46c9a51e7d3b971a0c0ffcf94b579d22450028f5
The function will be used in the case of KeyframeEffect::SetTarget too.
MozReview-Commit-ID: G6ipjxaIJsW
--HG--
extra : rebase_source : 609fa17d698612df21d9cac469e6997582dcca69
It might be possible that we can check whether an animation is being tracked
by the pending animation tracker without this function to count layout flush
since we force to flush layout if there is any pending animations [1]. But
it will probably result complicated test cases. So to make test cases simple,
we introduce a new function which just checking whether a given animation is
being tracked by the pending animation tracker.
[1] https://hg.mozilla.org/mozilla-central/file/3d20b0701781/layout/base/nsRefreshDriver.cpp#l1957
MozReview-Commit-ID: 4lWuOYCucaD
--HG--
extra : rebase_source : a42866d1b9828820c112ac8f756372648da8763f
This adds reporting of nsMemoryReporterManager's internals. Currently we just
report the weak and strong ref hashtables which have shown up in DMD reports.
The new entry is '/explicit/memory-reporter-manager'.
--HG--
extra : rebase_source : 53e4cbf127101489edfe85f31088cd049369cef8
extra : histedit_source : 1575adfcfb9d6492a51ab84cf417e07466068939
Also change PlacesUtils.history.removeVisitsByFilter to be able to remove by transition type.
MozReview-Commit-ID: Bkiv0ScUi07
Differential Revision: https://phabricator.services.mozilla.com/D2056
--HG--
rename : toolkit/components/places/tests/unit/test_download_history.js => toolkit/components/places/tests/history/test_download_history.js
extra : moz-landing-system : lando
The JPEG decoder will currently only post an invalidation when it has
processed all of the rows it is able to. If it is has all the data, that
means it must fully decode before invalidating. This causes very large
JPEGs to appear in large chunks which feels janky compared to slowly
appearing row by row with the refresh tick. With WebRender, it also
allows us to upload less data per frame update which can be another
source of jank.
Automatic update from web-platform-testsSplit up WebCryptoAPI/derive_bits_keys/ with `variant`
Also use .any.js.
Fixes#11203.
--
wpt-commits: 864cba25d0ac3d2f49e851623370f565ca293cbe
wpt-pr: 11204
