Just notice these precision errors are fixed by our other patches (i.e.
not by this patch series). Anyway, it's time to remove the tolerance.
MozReview-Commit-ID: 2ZDoRhuVOL8
--HG--
extra : rebase_source : 585ddcc4640ef9c8f5875d586e371b101626505d
We want to always use Servo animation backend on the compositor.
However, Android doesn't support Stylo now, so add a defined flag for it.
MozReview-Commit-ID: 63MnTBnq6yv
--HG--
extra : rebase_source : dce46737f81e4e217e9fd67b6bec722994dca6a2
Use the new added FFI, Servo_ComposeAnimationSegment, to compose an
animation segment from Servo backend on the compositor.
MozReview-Commit-ID: LNgpCSIlDl9
--HG--
extra : rebase_source : 5b5c145fae877b4f4b01ea54259737dc9dad2951
We will use Servo backend on the compositor, so implement this for opacity.
MozReview-Commit-ID: BeWR2nBSbjb
--HG--
extra : rebase_source : eb5db3cf04640a83f13857984e792a949f26bcc7
These are inter-dependent patches for bug 1340005. We add two FFIs to create the
AnimationValues of Opacity and Transform because we support these two properties
on the compositor. Besides, we factor out some common function in glue.rs, so we
can use the same code path for both main-thread and compositor-thread animations.
---
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix [Bug 1340005](https://bugzilla.mozilla.org/show_bug.cgi?id=1340005).
- [X] These changes do not require tests because we have automatic test coverage on Gecko already, and Servo doesn't support compositor animation for now.
Source-Repo: https://github.com/servo/servo
Source-Revision: 4e2c0e3277dda5d8bf462602268bbc1ec8ea26f7
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 66c1dd18d57495d78729a669ec255c087b42c5e1
Removes the XPCOM interface for nsIDOMHTMLMenuItemElement, replacing it
with binding class usage.
MozReview-Commit-ID: 9HtCmwKyV1W
--HG--
extra : rebase_source : d56ee91a46d48c9d8698765b520a585361813a26
This extends the fix in bug 1373802 to account for extra levels of
display item nesting. If those extra intermediate display items don't
push any clips we still want to pick up the ClipAndScroll from the
enclosing ancestor that has it.
MozReview-Commit-ID: AmxRz4fBKnX
--HG--
extra : rebase_source : ae12a9f797ab201169ff199d0d42a29df51ee1cb
We already support cases where we have scrolling clips applied to fixed
items. However if we had to build nested clips inside those items, then
those nested clips would not properly inherit from the scrolling clips.
This patch addresses that case.
MozReview-Commit-ID: CWp1x0EsyaP
--HG--
extra : rebase_source : f8c80ace2da39edebaabd5339670a68038a18489
In Unified Telemetry toolkit.telemetry.enabled controls whether we send base
collection data or extended collection. The difference is mostly in volume, not
in kind (though extended collection has a little stricter testing and monitoring
requirements).
Since the Preferences UI change in Firefox 56, users no longer have the ability
to change toolkit.telemetry.enabled. This is a good thing as for pre-release
users very few disabled extended collection, and even fewer release users
enabled it. This provides uniform collection based on channel which should
eventually net us some efficiencies.
Until then we need to align our use of the toolkit.telemetry.enabled pref with
the UI change that has already shipped. This is accomplished by locking t.t.e
to 'true' on pre-release channels and locking it to 'false' on everything else.
This doesn't apply to Android as it doesn't (yet) use Unified Telemetry. t.t.e
means something rather different there.
MozReview-Commit-ID: EOpWm8b0jWA
Because nsCString is nicer than UniqueFreePtr<char>.
The patch also streamlines pref_savePrefs(). And also changes StrEscape() to
always put quotations around the result, because that's needed in both call
sites.
MozReview-Commit-ID: HT7HZz4QiSN
--HG--
extra : rebase_source : 442bb6002e004803a9ecb637239a000f11ec5774
First, the patch removes the return values from PrefTypeFlags::Set*(). They
allow chained calls, but they're barely used and they just make the code harder
to read.
Second, the patch changes pref_SetValue() to not modify and return the pref
flags. It's clearer if the flags changing is done separately. This requires
passing pref_SetValue() the old type instead of the flags.
MozReview-Commit-ID: HZVS2TIlBIY
--HG--
extra : rebase_source : 6638244214cda15ceae5a1930659aed434d8261b
