For most of the functions we call on this frame there will be no difference in
result since the transform styles are inherited from the style frame to the
primary frame. However, for Combines3DTransformWithAncestors() at least, which
calls IsCSSTransformed(), the result will differ.
Differential Revision: https://phabricator.services.mozilla.com/D23283
--HG--
extra : moz-landing-system : lando
There are many bugs regarding our use of EffectSet::GetEffectSet(nsIFrame*)
because the intention of the caller is not clear. If it is called for the
primary frame of display:table content do we expect it to get the EffectSet
associated with the style frame or not? Generally it depends on if we are
looking for transform animations or not.
Rather than inspecting each call site and making it choose the appropriate frame
to use, this patch introduces a new method to EffectSet to get the appropriate
EffectSet based on the properties the caller is interested in.
This patch also uses this function in FindAnimationsForCompositor which in turns
fixes the glitching observed on Tumblr that arose since a number of places in
our display list code were passing the style frame to
EffectCompositor::HasAnimationsForCompositor.
Over the remainder of this patch series we will convert more callers of
EffectSet::GetEffectSet(nsIFrame*) to this new method before renaming
EffectSet::GetEffectSet to GetEffectSetForStyleFrame to make clear how the
method is intended to work.
Differential Revision: https://phabricator.services.mozilla.com/D23282
--HG--
extra : moz-landing-system : lando
It took me a long time to understand why
KeyframeEffect::HasEffectiveAnimationOfPropertySet behaved so differently to
KeyframeEffect::HasAnimationOfPropertySet. This patch attempts to clarify that
while making KeyframeEffect::HasEffectiveAnimationOnPropertySet a little more
generally useful. This will allow us to tidy up the various animation checks in
nsLayoutUtils later in this patch series.
Ultimately, however, we should make this check part of the regular compositor
animation vetting machinery in bug 1534884. That should remove a number of
inconsistencies such that we don't need the extended comments added in this
patch.
Differential Revision: https://phabricator.services.mozilla.com/D23281
--HG--
extra : moz-landing-system : lando
The trouble with utility functions that take an nsIFrame is it's not clear what
the caller's intention is. For example, with
nsLayoutUtils::HasCurrentTransition, is the caller asking for transitions on
that frame? Or animations on _both_ that frame and its corresponding
style/primary frame?
Probably the caller hasn't even thought about it and there are likely to be bugs
when display:table content is encountered.
Where practical it's much better to take an element/pseudo pair since it's clear
that the caller is concerned with all animations (or transitions in this case)
on the element regardless of how it is represented in the frame tree.
This patch updates nsLayoutUtils::HasCurrentTransition to take an element/pseudo
pair and moves it to mozilla::AnimationUtils at the same time.
Differential Revision: https://phabricator.services.mozilla.com/D23280
--HG--
extra : moz-landing-system : lando
There is no need to have an anonymous function after we replace all `var` to `let`, now those variables won't pollute outer scopes.
Differential Revision: https://phabricator.services.mozilla.com/D20028
--HG--
extra : moz-landing-system : lando
In order to keep the local variable only visible inside the function scope, we should only use 'let' for those variables.
Differential Revision: https://phabricator.services.mozilla.com/D20027
--HG--
extra : moz-landing-system : lando
Remove those funcitons which are used to implement the previous way to move the cue box.
Differential Revision: https://phabricator.services.mozilla.com/D19610
--HG--
extra : moz-landing-system : lando
According to the spec 7.2.10, step1 to step10 (snap-to-line is true) and step1 to step2 (snap-to-line is flase) [1], we would adjust cue box's position depending on the algorithm.
The algorithm would calculate the cue box's top (or left) position depending on the writing direction, and move the box to the specific position.
However, if the cue box is overlapping with other cue boxes in the rendering area, we would still need to adjust its postion, which will be implemented in next patch.
[1]
https://w3c.github.io/webvtt/#ref-for-webvtt-cue-snap-to-lines-flag-12https://w3c.github.io/webvtt/#ref-for-webvtt-cue-snap-to-lines-flag-13
Differential Revision: https://phabricator.services.mozilla.com/D19609
--HG--
extra : moz-landing-system : lando
It's confused that we have both simpleBoxPosition object and BoxPosition object, we should only use one format to perform all box related operations.
Therefore, BoxPosition should be able to be initiaized by StyleBox, HTMLElement or BoxPosition.
In addition, as `right` and `bottom` can be calculated from other attributes, we remove these two attributes from BoxPosition, and use getter to get the correct value, which can reduce some unnessary modification when we changes the `height` or `width`. In order to implement a more readable getter, so we change `BoxPosition` to class-based.
Differential Revision: https://phabricator.services.mozilla.com/D22809
--HG--
extra : moz-landing-system : lando
When calculating font size, we should use the original bounding box as a reference, or it would cause incorrect font size scale.
Differential Revision: https://phabricator.services.mozilla.com/D20026
--HG--
extra : moz-landing-system : lando
When close to int64_t's limit, the int64 can't be precisely converted to
double because of rounding error, rounding-up is also allowed. To ensure
a double `d` is within int64's limit, we should check
`d < std::numeric_limits<int64_t>::max()`, instead of `<=`.
Because `std::numeric_limits<int64_t>::max()` might be converted to a larger
double, when they are equal, we can't be sure if `d` is indeed within the actual
int64 limit.
Differential Revision: https://phabricator.services.mozilla.com/D23680
--HG--
extra : moz-landing-system : lando
`Selection::Extend()` is too slow but editor and ContentEventHandler use it in
some places. We should make them use `Selection::SetStartAndEndInLimiter()` or
`Selection::SetBaseAndExtentInLimiter()`. The former is usable only when caller
guarantees the start point is prior to the end point in the DOM tree.
Otherwise, we need to use the latter even though it's slower than the former.
Differential Revision: https://phabricator.services.mozilla.com/D23462
--HG--
extra : moz-landing-system : lando
`EditorBase::SelectEntierDocument()` uses `Selection::Extend()` but it's too
slow. It should use `Selection::SetStartAndEndInLimiter()` instead.
Additionally, `TextEditor::SelectEntierDocument()` shrink the result of
`EditorBase::SelectEntierDocument()` with `Selection::Extend()` if there is
a `moz-<br>` element. So, `TextEditor::SelectEntinerDocument()` should set
its expected selection with a call for saving the runtime cost.
Then, we don't need to make `EditorBase::SelectEntierDocument()` as non-pure
virtual method. So, this patch makes each its callers call
`Selection->SelectAllChildren()` directly.
Differential Revision: https://phabricator.services.mozilla.com/D23461
--HG--
extra : moz-landing-system : lando
`Selection::Extend()` is too slow because:
- it may create some `nsRange` instances.
- it users `nsContentUtils::ComparePoints()` multiple times.
Therefore, we can improve the performance if we can stop using it in some
places. First, this patch creates `Selection::SetStartAndEnd()` and
`Selection::SetStartAndEndInLimiter()` for internal use. They remove
current ranges, reuse `nsRange` instance as far as possible and add new
range which is set by their arguments. Then, this patch makes
`Selection::SelectAllChildren()` stop using `Selection::Extend()`. At this
time, this fixes a web-compat issue. `Selection::Expand()` cannot cross the
selection limiter boundary when there is a limiter (e.g., when an editing host
has focus). But we can now fix this with using the new internal API.
Note that methods in editor shouldn't move selection to outside of active
editing host. Therefore, this patch adds `Selection::SetStartAndEndInLimiter()`
and `Selection::SetBaseAndExtentInLimiter()` for them.
Differential Revision: https://phabricator.services.mozilla.com/D23459
--HG--
extra : moz-landing-system : lando
Looks like these three APIs slipped through when shipping v1, but no other
vendor supports them, so no reason to be here.
I don't think there's any harm in letting the implementations keep living in
DocumentOrShadowRoot, but let me know if you think otherwise and I'll move them
to Document.
Differential Revision: https://phabricator.services.mozilla.com/D23577
--HG--
extra : moz-landing-system : lando
Reusing an existing wpt test. That particular test happens to be enabled in Firefox, unlike most Feature Policy/Reporting API tests.
Differential Revision: https://phabricator.services.mozilla.com/D23675
--HG--
extra : rebase_source : eac208adb1783bde2d0fac5ccb311291219bd50b
Brian Birtles
shindli
Alastor Wu
violet
Masayuki Nakano
Sebastian Hengst
Ciure Andrei
Andrea Marchesini
longsonr
Timothy Nikkel
Coroiu Cristina
Csoregi Natalia
Mark Banner
Boris Zbarsky
Emilio Cobos Álvarez
Narcis Beleuzu
Brindusan Cristian
Oana Pop Rus
Olli Pettay
arthur.iakab
Christoph Kerschbaumer
Chris Peterson
Thomas Nguyen
Jean-Yves Avenard
Alex Gaynor
Byron Campen [:bwc]