Enlarge the touch target of the caret to the left, bottom, and right by
59% (13px) per bug 1262755 comment 7.
Since the touch target becomes larger, the carets on the <input> in
previous test might cause the next test to fail on <textarea> because it
will press on the caret when trying to focus on <textarea>. Add <br>
elements to testAccessibleCarets.html to separate these test fields.
MozReview-Commit-ID: JIwmuHJ2QsQ
--HG--
extra : rebase_source : 6fbfede7cc0e395402b5858d74480dcdd5606c35
Add a pref "layout.accessiblecaret.always_show_when_scrolling" defaults
to true on all platforms except b2g. When it is set to false, the carets
will be hidden during scrolling, which is the current behavior before
applying this change.
The pref "layout.accessiblecaret.extendedvisibility" was added for
Fennec to keep ActionBar open when carets temporarily hiding during
panning or zooming. Now we make carets always show by default, so the
pref can be removed. However, the floating toolbar still need to be
notified when the scrolling begins, so we dispatch "scroll" instead.
In gtest, the preference changes were in the middle of the test
function. To make the preference change clearer, I add new pref changes
or move the existing ones to the beginning of the test functions.
The 250ms transition effect added in ua.css is per request of UX
designer in bug 1249201 comment 12.
MozReview-Commit-ID: 8NGvDLPbtNY
--HG--
extra : rebase_source : 3f7a9ebdf4c70b0282dbf9e8f18cbe5cca656dbe
When the carets are scrolled by APZ, they will hide and dispatch a
"visibilitychange" reason. The floating toolbar (ActionBarHandler.js) on
Android listens to the event to update its visibility.
Now we want to show carets continuously when scrolling the page, so it
make no sense to dispatch a "visibilitychange" reason. However we still
need to notify the toolbar that the carets are scrolling by apz.
Therefore, we need a this new "scroll" reason. It will be dispatch in
AccessibleCaretManager::OnScrollStart() in Part 2.
MozReview-Commit-ID: F9znxHV3xCZ
--HG--
extra : rebase_source : 89914ebe5ed4cbcb5a3fd792a9f260e4c389fe84
Some tests are expected to fail until Bug 1216843 and 1216844 are resolved, so that
we specify that on the meta file `setFrames.html.ini`.
MozReview-Commit-ID: 6z2P1KkGJhb
--HG--
extra : rebase_source : 4e679d322a6d772de6488b58f70117908633433a
Extract a lot of tests from keyframe-effect/constructor.html and add some
documentation so that we can reuse them in other tests. This helper will
be used when we want to test these API:
* KeyframeEffect(ReadOnly) Constructor
* KeyframeEffect.setFrames()
* SharedKeyframeList Constructor
* Animatable.animate()
and so on.
MozReview-Commit-ID: 5jZbXyPFHih
--HG--
extra : rebase_source : 63f4afc865378be3ae67cad5d6a389564c67c6fe
WebIDL referes to KeyframeEffect::SetFrames(), which is derived from
KeyframeEffectReadOnly::SetFrames() in terms of implementation.
In addition, make KeyframeEffectReadOnly::ConstructKeyframeEffect call
KeyframeEffectReadOnly::SetFrames() to simplify the code.
MozReview-Commit-ID: 7ASbtoN7Tnp
--HG--
extra : rebase_source : c398ff7154c4533255f56c7ca13314e440eb6258
Like Animation.finished, this will likely change to a cancelable promise in the
future (assuming such things materialize) so we should not ship it for the
time being.
Pref "media.decoder-doctor.notifications-allowed" defines which notifications
may be forwarded to the front-end (based on the web-console message ID for
that situation). This allows fine-grained filtering.
The current default is to only notify the user about Widevine requests when WMF
and Silverlight are missing (because Widevine does not include an AAC decoder).
MozReview-Commit-ID: KPFH5XjuwnZ
Analyze the diagnostics information gathered so far, and dispatch
notifications as appropriate.
The most important case in this bug is when Widevine is requested but WMF and
Silverlight are missing.
The generic case of WMF missing (when needed to play) is there too.
Note: Currently no notifications are actually sent to the front-end by default,
the following patch will add filtering to allow/prevent targeted notifications.
MozReview-Commit-ID: EB9PKrMgKSr
Record diagnostics information about whether the GMP CDM failed to load
(though currently impossible!), and which GMP is used in the current media
format check.
MozReview-Commit-ID: 4B8kDTAiV6b
Media Key System access requests are now recorded with their success/failure,
as well as accompanying issues of importance.
In this bug we focus on the Widevine-with-no-WMF case.
MozReview-Commit-ID: ElBN6cXKwAW
Some refactoring, clean-ups, etc.
The main change is that the can-play status is passed when diagnostics are
finally recorded. This will help when introducing different types of
diagnostics in future patches (e.g., Key System issues).
MozReview-Commit-ID: 182ePlrMqn4
