Rather than passing around a bool flag to indicate if we should be creating
an AnimationCollection when none is found, it would be a lot easier to read
if we simply introduce a separate method for this.
MozReview-Commit-ID: 6bg8jGoH5pL
By moving GetAnimationCollection to AnimationCollection itself, we can remove
a bunch of virtual methods on the animation managers, simplify call sites,
and provide better type safety by ensuring a correspondence between element
property names and concrete animation types.
One change in behavior, however, is that in doing this we can no longer
add any newly-created AnimationCollection to the corresponding manager's linked
list of collections inside GetAnimationCollection. Instead we take a bool
outparam to indicate if a new collection was created and leave managing the
linked list to the manager. This is just a temporary measure, however, since
by the end of this patch series will will eliminate this linked list altogether
along with this flag.
MozReview-Commit-ID: 1jsc4QcmVDg
This patch templatizes the type of Animation stored in an AnimationCollection.
This allows us to remove a number AsCSSAnimation() calls in nsAnimationManager.
This patch also removes the AnimationPtrArray typedef. In its place we
introduce OwningCSSAnimationPtrArray and OwningCSSTransitionPtrArray but we
don't use these as widely. There was some comment previously that the typedefs
in animation code make it hard to read, particularly when these typedefs don't
make it clear if the data type is an owning reference or not.
In doing this we need to templatize CommonAnimationManager as well and move the
implementation of its (few) methods to the header file. We may be able to
remove the need for templatizing CommonAnimationManager later in this patch
series depending on how we ultimately decide to handle the lifetime of
AnimationCollection objects.
CommonAnimationManager::GetAnimationCollection is a bit messy but this will be
significantly tidied up in subsequent patches in this series.
MozReview-Commit-ID: 3ywatY53pRR
- To avoid confusion, call the blinking cursor (nsCaret) "cursor" so that
AccessibleCaret can be called caret for short.
- Add second_caret_location() as a helper function, and use it in
selection mode tests.
MozReview-Commit-ID: IKN6KuR92HE
--HG--
extra : rebase_source : c247ad6b61bc1b1cc3c4d8784584e19d9ef5c1ea
* Inline some of the open_*_html methods since they're called only once.
* Save test running time by finding the elements needed in tests instead
of find all of the elements in open_*_html methods.
* Remove test_long_press_to_select_non_selectable_word() since it's
covered by test_focus_not_changed_by_long_press_on_non_selectable().
* Use hyphen for element ids.
* Replace "left" and "right" caret by "first" and "second" caret,
respectively.
MozReview-Commit-ID: Ey5m5zO3HYc
--HG--
extra : rebase_source : c94b84ced75560ce1167cda35ee94dd4cc81ee4d
Remove _test_touch_caret_hides_after_receiving_wheel_event() completely
since it was a test only for touch caret, which is a leftover in bug
1221459.
MozReview-Commit-ID: 4szwuG6t5SF
--HG--
extra : rebase_source : 85a201d76016da65f14cd2cc0a641c342e266904
I don't feel these tests are helpful. It's unlikely that someone will
accidentally turn on AccessibleCaret on desktop platforms without being
noticed. Remove these tests also reduces the test running time.
MozReview-Commit-ID: 33RQQSy77gZ
--HG--
extra : rebase_source : 5cd7fd77a48f07ee137d8140481ea6210070d139
This is needed because blending for nsDisplayBackgroundImage items will soon
happen outside of nsDisplayBackgroundImage::Paint, it will be done by an
nsDisplayBlendMode item that wraps the nsDisplayBackgroundImage item.
MozReview-Commit-ID: 20cILOGVFEG
--HG--
extra : rebase_source : 306725c99a1cd8d450149482817b8b51bc660908
We're going to use it both for background-blend-mode and for mix-blend-mode.
MozReview-Commit-ID: 6zKCDSkLspc
--HG--
extra : rebase_source : 81b4691d2b74e56c634bdf08f85636ba2abbf486
I've decided to fix this in a very explicit way. The only "magic" part that's
left is how we decide that the AGR of the perspective item is outside the
scrolled frame (and I'm not sure myself how that works).
I didn't want to change what scroll clips we set on what items, because the
scroll clip really belongs on the perspective item, because that's the item
that needs to be clipped, and it should also be the item that should be
scrolled if it weren't for the fact that APZ wouldn't know that it should
apply the perspective transform before the APZ transform.
MozReview-Commit-ID: BBw8VPohQI4
--HG--
extra : rebase_source : 9e11441af2b5dab93a5908236e153fc6cd2c3d8b
extra : histedit_source : 7b3dd75afa92346856765284be48df5618821326
This isn't really about regular clips, it's about scroll clips. If the inner
item has an unnecessary scroll clip (one that's already on the parent), this can
cause the inner item's bounds to be larger than necessary because, after the
first patch in bug 1238564, it will include the whole bounds of async-scrollable
scroll frames.
Also, if e.g. the inner item is an opacity item, and it has a scroll clip that's
not just the innermost ancestor scroll clip of all of its children, then
FrameLayerBuilder's mContainerBounds == mAccumulatedChildBounds assertion can
fail if the opacity item gets flattened away, because the child bounds won't
have been enlarged for the scroll clip.
There must be a better way to do the clip resetting in
nsFrame::BuildDisplayListForStackingContext - the code is not pretty at all.
But I'd rather get the tests passing first before we figure out how to clean it
up.
MozReview-Commit-ID: E1DdpN546va
--HG--
extra : rebase_source : ecf4774a47978fb0aa5ebde9346cf464ebc60ab6
extra : histedit_source : 9395ca5f74413d887df3b7fa54cad726742dca30
Always use an ancestor scroll clip of all direct children, or the original
scroll clip if the children don't share the same scroll clip tree.
Unfortunately this requires another pass over the stacking context display list.
Also, fix clips, scroll clips and creation order of blend items:
If a clipped mix-blend-mode item contains absolute / fixed positioned items,
those items should not be clipped, same for blend container items.
When a transform item contains blend modes, create the blend container inside
the transform.
Don't do tree comparisons on scroll clips from different scroll clip trees.
If the inner scroll clip is nullptr, because it was cleared, it will look like
it's the ancestor of the outer non-nullptr scroll clip.
These changes don't look very related, but it was very hard to get tests passing
with only some of the changes and not the others, and after having spent two
weeks on this patch I'm not thrilled about going back and checking exactly which
change was necessary to fix which test failure.
MozReview-Commit-ID: IKGciUBrdNa
--HG--
extra : rebase_source : e570f16ecedd80cba16051f0e1ac66764bc95815
extra : histedit_source : fcfbcbc254aaf93594d9d80c117d6ec945805993
This makes sure that for example the bounds of an opacity item are not empty if
the opacity item contains a scroll frame whose contents are currently scrolled
offscreen but still inside that scroll frame's display port.
On its own, this changeset causes test failures due to missed optimizations
because the bounds of many opacity items are now too large. That's because of
the way we're setting scroll clips on opacity items at the moment: Even if the
opacity is inside a scroll frame, we're currently only setting that scroll
frame's scroll clip on the opacity item's contents, not on the opacity item
itself, because the opacity item might also contain other items that are not
scrolled by this scroll frame.
The next patch in this bug will make us only do that when necessary.
MozReview-Commit-ID: 9TtcJ7eQE7U
--HG--
extra : rebase_source : 51cab60bd27e1a7e3c2d6b8d791b79fe3b3baa94
extra : histedit_source : ba421898e442d08f7f711d13f71a693c34d908bb
Although this makes some places more complicated, code should generally
be simpler and clearer. It could slightly improve performance on x64 for
functions with more than four parameters, since it makes more data be
passed via registers rather than the stack.
MozReview-Commit-ID: D0GM2Jyrr6W
--HG--
extra : source : bd88a2e478e23edf1845f724a32fef908c8cc007
Although this makes some places more complicated, code should generally
be simpler and clearer. It could slightly improve performance on x64 for
functions with more than four parameters, since it makes more data be
passed via registers rather than the stack.
MozReview-Commit-ID: D0GM2Jyrr6W
--HG--
extra : rebase_source : 29961e56b5fe14b244046b3dc52b1f922c206218
Each warning message is generated only when getPropertyState() is called.
MozReview-Commit-ID: C03ZSvPv9ff
--HG--
extra : rebase_source : 5932957f8f0b171c7b100b1c22e70513959c819e
Those message will be modified in part 4 (localization).
MozReview-Commit-ID: 6TMUxemVLcu
--HG--
extra : rebase_source : 65ef1879b3e606ae6dc279981b1e995c7b2cd40b
Specific changes:
- flexbox-table-fixup-001a.xhtml previously tested that table parts would get wrapped in an anonymous table, which would form a single flex item. This patch changes it to instead test that each table-part forms its own flex item.
- flexbox-table-fixup-001b.xhtml previously was a "belt and suspenders" afterthought to its "001a" counterpart. It verified that flex-item properties (like "flex") had no effect on table parts in a flex container. This patch removes this test (since it's no longer valid) and renames the "001a" test to simply "001" as a result.
- flexbox-with-pseudo-elements-003.html previously tested that ::before/::after pseudo-elements with table-part display values would have their flex-item-related properties ignored (because they'd be wrapped in an anonymous table). This patch flips that expectation, because now these pseudo-elements will directly become flex items and these properties should be honored.
--HG--
rename : layout/reftests/w3c-css/submitted/flexbox/flexbox-table-fixup-001a.xhtml => layout/reftests/w3c-css/submitted/flexbox/flexbox-table-fixup-001.xhtml
PGO builds on Visual Studio 2015 Update 1 did not take kindly to
MOZ_CONSTEXPR in this file, causing a startup crash (for reasons
I can't explain). Switching to literal "const" makes the crash
go away.
MozReview-Commit-ID: K1A43NIa6lG
--HG--
extra : rebase_source : 16c57ae79cb642b5d2945425144c726c119371b4
This is to support Firefox Android L style carets assets that the two
carets always look like tilt.
This patch is derived from a WIP patch by Mark Capella
<markcapella@twcny.rr.com>
MozReview-Commit-ID: H3nKLz6HcpM
--HG--
extra : rebase_source : b3a77b0bb8aaea8f010002f54fde075c9d469711
It reduces the number of malloc/free calls and may reduce malloc heap
fragmentation.
--HG--
extra : rebase_source : 9ca0b27fc29181667be924116807186e8eb1c1fa
This makes these lines shorter, and brings us into alignment with the Mozilla Coding Style Guide. See mozilla.dev.platform post "Proposal to alter the coding style to not require the usage of 'virtual' where 'override' is used" for more info.
nsLayoutUtils::CalculateCompositionSizeForFrame() is not affected by the
document resolution when called for the root content document's root
scroll frame. When determining the root composition bounds in order to
calculate a displayport base, if the frame used is the RCD-RSF we must
be sure to scale the bounds ourselves by the document resolution.
MozReview-Commit-ID: ATctmEYvWIJ
--HG--
extra : rebase_source : ba96e7ecc2cefdbeacb08fbd3f5817819dd933c8
In my original design, I treat eTouchCancel to be like eTouchEnd for
ending a caret dragging procedure.
However when pointer events is enabled, it sents an eTouchCancel event
after the eTouchStart event whose primary usage is to be converted to
pointer events, which then cancels the normal caret dragging procedure.
Moreover, when pointer events is disabled, we don't get eTouchCancel
during a normal caret dragging scenario, so we don't really need to
handle eTouchCancel anyway.
MozReview-Commit-ID: GKju2Tp0q3Q
--HG--
extra : rebase_source : 31da189fc5543c7df0d748df004fc67c87f4da7f
This patch is generatedy by applying clang-format on
AccessibleCaretEventHub.cpp.
MozReview-Commit-ID: 10qPJ47CVMH
--HG--
extra : rebase_source : ff39be696ef4cd93ffbe0b9e7c95920aa03a6893
When enabling "dom.w3c_pointer_events.enabled", we might get a
eTouchCancel event without any touch data. That is, aEvent->touches is
an empty array. We need to make sure it's non-empty before accessing
aEvent->touches[0].
MozReview-Commit-ID: BQUsrJjHHEl
--HG--
extra : rebase_source : d5f435792ecc0cac79937121fa03ce6f22c59582
I think we're going to have a fair number of things like this, so I'd rather
put them all in one place, rather that defining them in the header for the first
consumer that uses the type.
There were two problems in the existing code (which was exposed by tests
that dynamically insert/remove items). First, the situation when
we have some pushed items two or more fragments away and then pull up
those. This creates a "hole" in the child next-in-flow chain like so:
grid-container-frag-0
child1-frag-0
...
grid-container-frag-1
...
grid-container-frag-2
child1-frag-1
After we reflow grid-container-frag-0 and it's still incomplete we will
reflow its NIF, grid-container-frag-1, but it will "stall" since it
doesn't have a continuation for child1. We need to make sure to
always pull up a fragment for that child. That's what the first hunk
is about in the patch.
Second problem is the opposite problem of pushing a child into a NIF
container that already has an OC child continuation, like so:
grid-container-frag-0
OverflowList = { child1-frag-0 }
grid-container-frag-1
OverflowContinuationsList = { child1-frag-1 }
When we reflow grid-container-frag-1 we'll pull in child1-frag-0
like so:
grid-container-frag-0
...
grid-container-frag-1
PrincipalList = { child1-frag-0 }
OverflowContinuationsList = { child1-frag-1 }
This is bad since we'll consume BSize twice here. The fix is
to move it our ExcessOverflowContinuationsList instead, like so:
grid-container-frag-0
...
grid-container-frag-1
PrincipalList = { child1-frag-0 }
ExcessOverflowContinuationsList = { child1-frag-1 }
That's what the second hunk in this patch does.
