The synthetic mouse move flushes animation styles during running test cases on
Linux, it breaks these tests!
MozReview-Commit-ID: DOT7m3fhrZi
--HG--
extra : rebase_source : 6fe04028073277276df9ae4a24ad62f9e4419d5c
We are going to use SimpleTest.js in the sub window.
MozReview-Commit-ID: HAAMnY7xDNn
--HG--
extra : rebase_source : 3600376a992abf5e1e55baba99bff1a656afdaa6
We shouldn't call synthesizeWheelAtPoint() in an rAF callback and observe
animation restyle makers there since we might end up observing an animation
restyle maker which is brought by flushing throttled animation styles for
hit-testing caused by the wheel event. Now we have sendWheelAndPaintNoFlush
which does not flush any styles before sending the wheel event, we use it.
MozReview-Commit-ID: 6WP2ExA7fAv
--HG--
extra : rebase_source : a2a5cea00fbe431dea8096b584a9f82c658158aa
Before this patch the child element actually did not move into the view and
observed an unrelated restyle maker. In the next patch we fix the observation
of the unrelated restyle maker.
MozReview-Commit-ID: 1DejqwF6hJg
--HG--
extra : rebase_source : ea6d6a48043f1b2a52ddedcbc41c321624a723d2
It much makes more sense to check the animation in out-of-view is throttled
and unthrottled once it got visible in a single test.
MozReview-Commit-ID: AZY5Xc0cbDF
--HG--
extra : rebase_source : bcdf999ee10283853c7b0bda8f450a53990a0e1c
Bug 1386489 means that ended is not reliably set in relation to the test
seeking machinery. This results in the following behaviour being possible:
- seekToNextFrame seeks to last frame
- the seek promise resolves and invokes check to see if video has ended
- ended is not yet set (race), so another seekToNextFrame is setup
- onended handler is invoked at some point (1st time)
- seekToNextFrame seeks again, remains at last frame
- oneended handler is invoked again due to the seek (2nd time)
- finish() has been called twice
This changeset should bandaid the above being possible.
MozReview-Commit-ID: BkskWUnaJQ9
--HG--
extra : rebase_source : 0108cf82a805136a87752d0128c1c0f2e7997ff6
- First, MOZ_DIAGNOSTIC_ASSERT_ENABLED is always true when MOZ_DEBUG is
set, so don't check for MOZ_DEBUG.
- Second, all the magic number assertions should be
MOZ_DIAGNOSTIC_ASSERTs instead of MOZ_ASSERTs.
--HG--
extra : rebase_source : 5601cd13604e21c46a9f0ad8b0b4d6fc399b853e
Some need initialization to happen, some can be skipped when the
allocator was not initialized, and others should crash.
--HG--
extra : rebase_source : d6c2697ca27f6110fe52a067440a0583e0ed0ccd
- Building is nightly channel only. Beta and release for Fennec 58 don't build
stylo. It means that the package size for 58 beta/release isn't incremented
by this change.
- The preference for stylo is still turned off Nightly 58. It will be turned on
59 after fixing some bugs for crashtests and etc. Our target to enable stylo
for Android is 59.
- ./mach bootstrap already installs clang etc to build stylo and bindgen.
Developers for mobile won't require additional build options for this change.
MozReview-Commit-ID: CIpYl8I5d7x
--HG--
extra : rebase_source : 6387704e4a94db080d4add10298cf1cc254ddec0
The earlier patches in this bug were written before we had
sophisticated binding generation so the types didn't match very well.
This fixes all of that.
MozReview-Commit-ID: DpcblpB8vxW
These tests were failing because of some misoptimizations that GCC did.
clang is generating correct code here, and the tests correctly pass, so
we can mark them as such.
NDK r15+ clang changed the code generation strategy for the __atomic_*
intrinics such that using them with 64-bit types now requires linking
with libatomic. Our current configure tests for libatomic doesn't catch
this, because the std::atomic implementation is such that it doesn't
require an external library, even for 64-bit types, whereas the
__atomic_* intrinsics do. The safest thing to do is to force this
configure check to always return true when we are compiling for
x86/Android with clang.
The NDK clang needs to be informed about the existence of a GCC
toolchain, so important programs like the linker can be located. With
this change, we're starting to use command-line options that are
incompatible with GCC, so we also add a check to inform the user about
the non-support for this configuration.
James Cheng
Evan Tseng
DimiL
Daosheng Mu
gasolin
Glenn Watson
btian
Hiroyuki Ikezoe
Bryce Van Dyk
Mike Hommey
Sebastian Hengst
ffxbld
Zibi Braniecki
Makoto Kato
Tom Schuster
Jorg K
Nathan Froyd
Jeff Muizelaar