The resizer in question is smaller in Ubuntu 16.04 than on other platforms (due
to smaller scrollbars in the default OS theme), so we need to target our click
closer to the corner of the element in order to hit the resizer.
MozReview-Commit-ID: Cz4MIKsOaGS
--HG--
extra : rebase_source : fdb852d924b7505ec2cfc2404ba632bf51ee09ee
Bug 1180564 dropped NSTextInput protocl implementation from ChildView but IMEInputHandler::SendCommittedText() still calls it via mView. Therefore, it fails to commit composition in widget level. Instead, we it should call insertText:replacementRange: of NSTextInputClient protocol.
Additionally, this patch adds a last resort path. If calling insertText:replacementRange: didn't commit composition in widget level, it calls TextInputHandler::InsertText() directly.
MozReview-Commit-ID: BZZypBqC0Mx
--HG--
extra : rebase_source : bef5612a933db3211400e9d8bd2848690de2d2e5
3rd-party-app could launch CustomTabsActivity, and could also configure
a custom action button. Now let CustomTabsActivity supports it by
creating a MenuItem.
MozReview-Commit-ID: 2KuMgBJy2gz
--HG--
extra : rebase_source : 93bcfb33001005d307dba68f898375ab7d86adb2
To support ActionButton in CustomTabsActivity, information should be
extract from intent.
MozReview-Commit-ID: 3C19U0EQfV6
--HG--
extra : rebase_source : a8d941a3fd740d5d8863e748b20de790b8bf589c
This variable is useless. So far we reference to a toolbar instance by
local variable. Removing it makes less ambiguous.
MozReview-Commit-ID: 8zrEKaB2H48
--HG--
extra : rebase_source : e35e3f87876ca497745585134018cff41536b9b0
These should be part of the tests for the transformed distance since that is
currently the only place where they can occur.
This patch also revises the test descriptions somewhat to make it clearer what
is being tested.
MozReview-Commit-ID: D4YfAiZUBYR
--HG--
extra : rebase_source : 778034d7bd02431cb2ebaee7da7e1fe3f745c400
(Once we remove the special clamping behvaior later in this patch series, the
added test here will fail if we don't add special handling for the case
when the progress is zero and we are in the delay phase.)
MozReview-Commit-ID: Dnon2soE1Se
--HG--
extra : rebase_source : c1045d168211bf73ff28102e7177653eedc8b6f2
We only use this once to test the timing function when applied to a keyframe.
Now that we have tests for this in
animation-model/keyframe-effects/effect-value-transformed-distance.html
we can drop the check here and simplify these tests considerably.
Also, 'progress' is always set so we can drop the check for an undefined value.
MozReview-Commit-ID: 39ajHZBRWBf
--HG--
extra : rebase_source : 548fcfadd97888be126f746bcd1b0113156ce034
This seems like a Gecko-specific test and even then it's not clear why we
expect the result could be different in this case.
MozReview-Commit-ID: Ix8jZLobwcA
--HG--
extra : rebase_source : 9068b8bbd3efc30a588d704eaee3d172824f176c
This doesn't need to be an array of objects when a simple array would do.
MozReview-Commit-ID: 1gtdhG5RPSy
--HG--
extra : rebase_source : ebe92fc91cd94d3b54277810e300b6bba570c8c5
These tests are generic enough to be used for either effect easing or keyframe
easing.
MozReview-Commit-ID: 5cpnkiCv0z1
--HG--
rename : testing/web-platform/tests/web-animations/resources/effect-easing-tests.js => testing/web-platform/tests/web-animations/resources/easing-tests.js
extra : rebase_source : eef374243f4a03c7a1fa8f01d04bf0457177848a
The purpose of these tests appears to be to check that a linear-equivalent
cubic-bezier timing function (e.g. 'cubic-bezier(0, 0, 0, 0)') does not affect
the result such as clamping values out of the [0, 1] range.
This test really is testing the calculation of the 'transformed distance' in
the "The effect value of a keyframe effect" so we move the test there and
rework it to more clearly test what it is intended to cover.
MozReview-Commit-ID: 9sEr7MlVZKL
--HG--
extra : rebase_source : 290f5d875db32f9396264b76652c02d8b2976bee
This set of tests are really just testing that we apply the timing function to
the animation effect so they belong in the appropriate part of the timing model
tests (and should check getComputedTiming not getComputedStyle).
I've also started to update tests to ES6 where appropriate since it seems
arrow functions, template literals, etc. are all supported on all UAs that
are implementing or likely to implement Web Animations.
MozReview-Commit-ID: 3kXao0Xi0BA
--HG--
extra : rebase_source : dd46913675b83fcb4c8c263b02c4d1c9cc23855f
