This adds testing for transitions on background-position-x/y, and makes sure we
no longer call check_distance for background-position, because
background-position is now a shorthand and no longer has its own distance
computation.
MozReview-Commit-ID: 82KVruCghGe
--HG--
extra : rebase_source : c7c85abc9bb7ff1987d7372635c0a9702715b761
This adds testing for transitions on background-position-x/y, and makes sure we
no longer call check_distance for background-position, because
background-position is now a shorthand and no longer has its own distance
computation.
MozReview-Commit-ID: 82KVruCghGe
--HG--
extra : rebase_source : 65e52287c141044df8ae490d461ebef3e8d403ec
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
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 two <br>
to testAccessibleCarets.html to separate the <input> and <textarea>.
MozReview-Commit-ID: JIwmuHJ2QsQ
--HG--
extra : rebase_source : 73b662980a5be55a4e3e31506437f2c26f65cd85
(This commit is effectively re-landing an assertion from changeset c1e9d6224c5a, aka bug 1208344 part 4. The rest of that patch is no longer needed, but this assertion is still useful.)
MozReview-Commit-ID: 7v5IwzS2CtP
(This commit is effectively re-landing changeset b3a36d79154f, aka bug 1208344 part 3. This re-landed version of the patch simply has unbitrotting fixes for indentation changes.)
MozReview-Commit-ID: BszOC5wyvBA
Currently if we have transition-property: 'all' and trigger a transition
on the 'color' property we will end up generating a transition on
-webkit-text-fill-color even if that property is disabled.
However, when we later call StyleAnimationValue::ToValue() in
nsTransitionManager::UpdateTransitions() to see if there are any transitions we
need to cancel, the comparison for currentValue != anim->ToValue() will pass
(since, as of the first patch in this patch series, ToValue() returns a null
value) so we end up cancelling the transition as soon as we create it).
Nevertheless, we will still trigger the warning introduced in the first patch
in this series when we call ToValue().
This patch stops us from creating transitions in the first place (and hence
triggering the warning). It also removes the code that suppresses transition
events for transitions on disabled properties since we should no longer be
generating such transitions in the first place (unless the pref is switched
while the transition is in motion which is probably not worth worrying about).
Note that we only test if the property is enabled for all content. This is
consistent with what we do throughout animation code including the existing
code in nsTransitionManager which iterates through shorthand sub-properties
using CSSPROPS_FOR_SHORTHAND_SUBPROPERTIES with the flag
nsCSSProps::eEnabledForAllContent.
The test case in this patch doesn't actually fail without this change, all it
does it trigger the warning in StyleAnimationValue::ToValue() introduced
in the first patch in this series. It's still a useful regression test however,
particularly if we later upgrade the warning in StyleAnimationValue::ToValue()
to a fatal assertion.
MozReview-Commit-ID: H9swDKLyiOf
I have verified that without the fix in the first patch in this series this
test fails, but passes with the fix applied.
MozReview-Commit-ID: JmncnapbVLa
This patch backs out changeset range 1f1884449dd4:0b5ed5e4a395 (all of the patches for bug 1208344) -- i.e. it backs out our support for "-webkit-box-orient". This patch also adds "fails" annotations to two reftests that depend on that feature, to reflect reality that these tests are now expected to fail (for the moment).
MozReview-Commit-ID: F8zGGg8R0Rn
The initial value of nsStyleDisplay::mWillChange is represented by an
empty array, and will-change is not so common, so we change it to use an
nsTArray.
nsStyleDisplay::{mTransitions,mAnimations} both always have at least one
element in it, so we change them to use nsStyleAutoArray rather than
nsTArray.
Existing uses of AutoTArray in style structs makes them non-memmovable.
We introduce this AutoTArray-alike class for use by those style struct
members that really do need to use an auto array's built-in allocation.
Per html spec, the disclosure triangle can be generated via "display:
list-item", I removed the code to generate the triangle in
SummaryFrame::SetInitialChildList(). That is, when a web page set
"display: block" to the summary, the triangle will disappear, too.
Now SummaryFrame does nothing and is going to be removed in Part 2.
Also summary element should not increment the counter as hinted as
"counter-increment: list-item 0" in the spec. Hence the change in
nsBlockFrame::RenumberListsFor().
The rendering hint in html spec:
https://html.spec.whatwg.org/multipage/rendering.html#the-details-and-summary-elements
MozReview-Commit-ID: DELGYFe3zGX
--HG--
rename : layout/reftests/details-summary/open-summary-block-style.html => layout/reftests/details-summary/open-summary-block-style-ref.html
extra : rebase_source : 4bd5493fb6a1108eea31aef1d89f563f781b753f
Add a new API in nsTransitionManager, so we can cancel transitions for a
specific element easily. The purpose of this API is for cancelling transitions
without dispatching the event.
--HG--
extra : rebase_source : 07483aebb8513dcd39c5e1805480dcbe6d3945b3
Although we know that the animation properties will always be filled in for
a transition in the cases where we need to query them (going forward we will
have a situation where an animation may only have frames, not properties, but
that will only happen when the animation isn't attached to an element or the
element is not attached to a document, but we don't run animations in that case
and cancel existing ones when we enter that state so although they *can* enter
that state, we'll never run these methods on them when they do), we still want
to move towards making frames the primary unit for interacting with animation
values since frames always exist and represent the public interface.
Ultimately it would be good to make the properties array on
a KeyframeEffect(ReadOnly) an encapsulated detail so that we can freely change
their structure (e.g. segments might not be the best setup, it might be better
to just have arrays of free-standing values to avoid the duplication of
values when segments are continuous).
This patch removes or encapsulates a few references to properties and
simplifies the code at the same time.
MozReview-Commit-ID: 3II36SYVoRE
When we go to switch CSS Animations over to using
KeyframeEffectReadOnly::SetFrames we will need a way to represent any filled-in
from/to values as nsCSSValue objects. These objects are built from the current
computed style. We currently use StyleAnimationValue::ExtractComputedValue for
this which returns a StyleAnimationValue. In order to convert this to an
nsCSSValue we can use StyleAnimationValue::UncomputeValue. However, in some
cases, the nsCSSValue objects returned by that method are dependent on the
passed-in StyleAnimationValue object.
This patch adds an overload to UncomputeValue that takes an rvalue
StyleAnimationValue reference and produces an nsCSSValue that is independent
of the StyleAnimationValue through a combination of copying data and
transferring ownership of data.
This patch also adjusts the return value for the case of filter and shadow
lists when the list is empty so that we return a none value in this case.
These are the only list types which are allowed to have a null list value.
Not only does this produce the correct result when these values are serialized
(the initial value for 'filter', 'text-shadow', and 'box-shadow' is 'none') it
also means that UncomputeValue should never return an nsCSSValue whose unit is
null which is important because when we later pass that value to BuildStyleRule
it will treat a null nsCSSValue as an error case (specifically, "longhand failed
to parse").
MozReview-Commit-ID: 4RoCn39ntiJ
In the next patch in this series, we would like to update the error handling of
the call to StyleAnimationValue::Interpolate in
KeyframeEffectReadOnly::ComposeStyle. Using AnimValuesStyleRule::AddEmptyValue
there, however, makes handling the error case difficult because we need a means
of clearing the allocated StyleAnimationValue.
However, simply using AnimationValuesStyleRule::AddValue means we will end up
doing needless allocations for StyleAnimationValue objects (the copy
constructor for which can result in performing potentially expensive heap
allocations, such as when lists are deep-copied).
Instead, we add a Move constructor to StyleAnimationValue and add an overload
of AnimValuesStyleRule::AddValue that takes an rvalue reference. This
provides a more consistent interface to AnimValuesStyleRule and avoids the
unnecessary allocations from copying StyleAnimationValue objects.
MozReview-Commit-ID: CaP1uPAgNnm
We need to re-evaluate html.css whenever "dom.details_element.enabled"
is changed to make the disclosure triangle for summary elements show up.
Reftests for details and summary will need the a live pref to work.
MozReview-Commit-ID: 9SN1fQBuwA7
--HG--
extra : rebase_source : c8eafde9d3a97908c44099219603f76087d484b9
This is a internal-only syntax for guarding rules from a boolean
preference. Nothing causes @supports rules to be re-evaluated except
html.css registered in Part 2.
This is needed for rendering the disclosure triangle of the
summary element by using "display: list-item".
Usage example:
@supports -moz-bool-pref("dom.details_element.enabled") {
/* css rules */
}
MozReview-Commit-ID: HDCa8zHxYTA
--HG--
extra : rebase_source : b7a72a48166edf1d486014ff37363ed8be9127d9
