We should not be declaring forward declarations for nsString classes directly,
instead we should use nsStringFwd.h. This will make changing the underlying
types easier.
--HG--
extra : rebase_source : b2c7554e8632f078167ff2f609392e63a136c299
In SMIL if a discrete calcMode is used, the keyTimes attribute may be used to
specify the times at which the various animation values are used, overriding the
regular 50% flip behavior (see nsSMILAnimationFunction::ScaleSimpleProgress).
However, this behavior is only applied when the calcMode is known to be
discrete. If the author specifies calcMode="linear" but
attributeType="stroke-linecap" then SMIL should fall back to discrete calcMode
including applying the special keyTimes behavior.
For the Servo backend, Servo_AnimationValues_Interpolate does not return an
error for discretely animated properties so SMIL does not recognize when we fall
back to discrete calcMode. This patch adds a check before performing
interpolation that tests if the property is a discretely interpolable one and,
if it is, returns an error so that we run SMIL's special discrete calcMode
handling.
MozReview-Commit-ID: FOp8XcNbvdu
--HG--
extra : rebase_source : 57ddb333855de111aa585fe894e99937681e5cd2
When display style is changed from 'none' to other in animation-only restyle
we need to resolve descendant elements' style that were in the display:none
subtree.
Three possible ways to resolve the descendant elements' style;
1) Traversing unstyled elements in animation-only restyle
We can't simply traverse unstyled elements in the animation-only restyle
since when we decided to traverse the unstyled elements we don't know yet
the elements will be initially styled or are in display:none subtree. It
will result that the new elements are styled in animation-only restyle,
it's undesirable.
2) Creating a SequentialTask and resolve the descendants' style with
ServoStyleSet::StyleNewSubtree()
We can't resolve the descendants' styles with ServoStyleSet::StyleNewSubtree()
in SequentialTask since at the moment we are still in servo traversal (i.e.
sInServoTraversal is true). That means AutoSetInServoTraversal fails
in PrepareAndTraverseSubtree().
3) Creating a SequentialTask and set restyle subtree hint and defer descendants'
restyle in a subsequent normal traversal
Note that, when we process throttled animations flush, we don't process
normal traversal so the descendants will not be traversed until normal
restyle happens but it will not be a big problem since it's really rare
that user clicks display animation element just at the right moment when
display property changes from none to other. Also, if it will be really
a problem, we should process *only* transform animations on the compositor,
it's ideally right thing to do. Display property never runs on the
compositor.
This patch takes the third approach.
MozReview-Commit-ID: Krxa3kkdIq4
--HG--
extra : rebase_source : 33e9db953f21168c76716329568191625bd15896
AddOrAccumulate in nsSMILCSSValueType.cpp sets initializes |valueToAdd| to
either &valueToAddWrapper->mGeckoValue or nullptr. It then asks
FinalizeStyleAnimationValues to fill it in. FinalizeStyleAnimationValues will
return false if it could not fill it in, in which case AddOrAccumulate returns
early. As a result, after the early return we can be assured that |valueToAdd|
is not null. However, valueToAddWrapper may still be null.
Changeset 4d87f2bf4b10369af0dd83a2ef962a23299ee8d9 from bug 1358966 changed this
code such that we pass a member of valueToAddWrapper to StyleAnimationValue::Add
where we used to pass a member of valueToAdd. As a result, we can end up passing
0x20 (since valueToAddWrapper is nullptr) to Add() and then trying to read from
it.
This patch makes us pass, instead, |valueToAdd| since we know that is guaranteed
to be non-null here.
MozReview-Commit-ID: 1YwT1lBHnUe
--HG--
extra : rebase_source : abec6995af68de13eacaccf7eca7b2d121eaedf3
The spec says,
font weight: interpolated via discrete steps (multiples of 100). The
interpolation happens in real number space and is converted to an integer by
rounding to the nearest multiple of 100, with values halfway between
multiples of 100 rounded towards positive infinity.[1]
However, our implementation pre-dates this spec text (bug 528234 landed Nov 2009
whereas the spec was updated in Mar 2012[2]).
This patch rounds the result by simply adding 50 to the result before we floor
it (which is good enough in this case because we don't need to worry about
negative values).
It also slightly simplifies the logic by re-using Clamp from MathAlgorithms.h.
[1] https://drafts.csswg.org/css-transitions/#animtype-font-weight
[2] 00c6286109
MozReview-Commit-ID: BjCg7MG70hW
--HG--
extra : rebase_source : 879ea18d7d1a49ff425d6e467081983a130a65e3
In case of gecko, we use only the StyleAnimationValue.
Whereas in case of servo, we use RawServoAnimationValue and
make it an array to store multiple values for shorthand sub properties.
MozReview-Commit-ID: 4PnWBk9WP2Q
--HG--
extra : rebase_source : a2b5878f14241c2cbf4adeeed3a0fa08ae230fa3
To traverse pseudo elements in animation-only restyle, the pseudo element
itself needs the animation-only dirty bit.
MozReview-Commit-ID: 11RfVqnPXfJ
--HG--
extra : rebase_source : d048c9a053c03bf3fef46fcbfd9cbd5f60204e1d
Our coding style says we should only use one of either 'virtual' or 'override'.
In the next patch I would like to add another override to this header so first
we should tidy up the existing declarations.
MozReview-Commit-ID: AFtMNvNCcNG
--HG--
extra : rebase_source : 60d0e4fc259ff05aa097a4cf2c10b75883b9deed
If we attempt to call animation-related methods on the Servo backend (e.g.
Servo_ComputedValues_ExtractAnimationValue) and pass a property that is not
(yet) animatable by Servo, it will panic so we should avoid passing these
properties.
An alternative, is to make methods like
Servo_ComputedValues_ExtractAnimationValue fallible by having them first check
if the passed-in value is animatable and return null in that case. That too, is
probably worth doing (call sites like KeyframeEffectReadOnly::EnsureBaseStyle
that assume it is fallible could assert that the result is non-null since,
provided that property is animatable, the method should still be fallible) but
refusing to animate these properties from the start is cleaner so we just do
that for now.
MozReview-Commit-ID: ESYcbkTtfXG
--HG--
extra : rebase_source : 60e4469d0883c49b77118f9235f0f4b369f6cd3f
I've propagated quirks mode information on some places. But we needed to pass
quirks mode to some other FFI functions to be able to handle that information
properly.
MozReview-Commit-ID: JovQWjN3YJx
--HG--
extra : rebase_source : bd25ba4276ae21ff4feb80e56b311202019268a0
We need another flag that represents allow-negative-number for SMIL, so
this enum will also comprise the another parsing mode that allows negative number.
MozReview-Commit-ID: IDFNppjGeB
--HG--
extra : rebase_source : 456f661b33346ff4a756a66c6accf4ab1a5f2f80
The two skipped tests (1 in layout/base/ and 1 in view/) both cause leaks while
running crashtests, so annotate them with a tracking bug (bug 1363000) filed.
MozReview-Commit-ID: GhSRt4wqu44
--HG--
extra : rebase_source : ed81c75251b35cee7f940b38e3998a6df3c1fcc6
This is just a minor refactoring to simplify ValueFromStringHelper before we
refactor it further in the next patch (and so we can re-use this definition to
produce debug warning for Servo since we don't handle negative values there
yet).
MozReview-Commit-ID: CfcnI2Be5di
--HG--
extra : rebase_source : 4e052cc37d24671159f32c3e0ca3bc48f5a73c54
Other browsers do not support any of these (IIRC), telemetry reports
essentially zero usage, and supporting them is contrary to the DOM spec.
Notes on specific events:
CommandEvent and SimpleGestureEvent: These are not supposed to be
web-exposed APIs, so I hid the interfaces from web content too
(necessary to avoid test_all_synthetic_events.html failures).
DataContainerEvent: This was a non-standard substitute for CustomEvent
that seemed to have only one user, so I removed it entirely and switched
the user (MozillaFileLogger.js) to CustomEvent.
ScrollAreaEvent: This is entirely non-standard, but we apparently expose
it deliberately to web content, so I didn't see any reason to remove it
from createEvent.
SimpleGestureEvent and XULCommandEvent: Can still be created from
createEvent(), but not by content.
TimeEvent: This is still in because it has no constructor, so there's no
other way to create it. Ideally we'd update the SMIL spec to add a
constructor. I did remove TimeEvents.
MozReview-Commit-ID: 7Yi2oCl9SM2
--HG--
extra : rebase_source : 199ab921acfc531b8b85e77f90fcd799b03c887b
We will use this in the next patch in this series to fetch the base style.
(I tried simply passing this as a parameter to GetBaseStyle but it proved to be
more complicated since all the overrides of GetBaseStyle would need to be
updated to take a parameter that would be irrelevant to most of them.)
MozReview-Commit-ID: Fdr4rFUlE9V
--HG--
extra : rebase_source : 26978951302b4764938959a065402f05220b6093
In the next patch we want to add a method called
GetUnanimatedStyleContextForElementNoFlush but that's much too long. Instead it
seems better to just drop 'ForElement' from all these methods since it should be
fairly obvious we are getting the style context for an element given that the
first argument is an element.
MozReview-Commit-ID: JQKaEuCKV2F
--HG--
extra : rebase_source : 3ba51f3b00d1ec7bc91102629d9c0abb88992fef
We will use this in a subsequent patch in this series to determine if we need to
fetch a style context at the beginning of ComposeAttribute (when we create the
nsISMILAttr) or not.
MozReview-Commit-ID: CFBNmmFNNef
--HG--
extra : rebase_source : 4729b2e1194649f461c353fa74d99b5b7829a077
In a subsequent patch we will extract a StyleAnimationValue from an
nsStyleContext. Rather than serializing it and then re-parsing it into
a StyleAnimationValue, this patch adds a method to directly accept
a StyleAnimationValue since that is what nsSMILCSSValueType stores internally
anyway.
MozReview-Commit-ID: KBaLYAzAlWZ
--HG--
extra : rebase_source : b42f25236fba52939e07c63f5195d10678ea12bd
This seems like an existing bug. If the content specifies
attributeType="yer:opacity", we should not try to animate it as a CSS property.
This patch adds a namespace check before we try to animate as a CSS property.
MozReview-Commit-ID: 1LpBa23ddqX
--HG--
extra : rebase_source : c5a4edb4c48bfd6116e58d4ef3eb91384ee86bd5
In bug 1315874 we will create a method to check if we're likely to need to
resolve base styles or not, and for that we need to extract the check for
whether or not we're animating a CSS property.
MozReview-Commit-ID: 9Ybsi91fro8
--HG--
extra : rebase_source : e2f72a7d807bfbe026fbd1a603cd993c3d502584
nsSMILCompositor::mCachedBaseValue is an nsAutoPtr<nsSMILValue> that we allocate
on the heap. It looks like we did that back in bug 533291 presumably because it
makes transferring these cached values between nsSMILCompositor objects cheaper.
One drawback of this, however, is that mCachedBaseValue has two null states:
the mCachedBaseValue pointer can be null, and the pointed-to nsSMILValue can be
a null value (i.e. IsNull() returns true).
Now that we have move ctors and operators defined for nsSMILValue we can
transfer these objects between compositors cheaply without requiring the object
to be allocated as separate heap object. This patch makes mCachedBaseValue just
a regular nsSMILValue class member (i.e. drops the nsAutoPtr).
There's a subtle difference in behavior with regards to the first sample.
Previously we would compare the (initially) null mCachedBaseValue pointer with
the passed-in nsSMILValue and set mForceCompositing to true. With this patch,
however, we will only set mForceCompositing to true if the passed-in
mCachedBaseValue is not null.
I believe this is correct, however, since if we don't call GetBaseValue in
ComposeAttribute we should not be setting mForceCompositing to true (something
else should ensure that gets set to true), and if we do call GetBaseValue the
result should not be a null nsSMILValue (except in some OOM cases where we don't
really care if we miss a sample). This patch adds an assertion to check that
GetBaseValue does, in fact, return a non-null value. (I checked the code and
this appears to be the case. Even in error cases we typically return an empty
nsSMILValue of a non-null type. For example, the early return in
nsSMILCSSProperty::GetBaseValue() does this.)
MozReview-Commit-ID: BRJFa4xMdxz
--HG--
extra : rebase_source : f3e3ca1e01e73610523bde7583e2a002d2473184
We will add to these includes later in this patch series so we sort them now so
it's clear where to add to.
MozReview-Commit-ID: CgqlS3f62nu
--HG--
extra : rebase_source : 009e8de1961cfd3d0f9cd72061e2e8f254f03cad
We want to use a similar model as Chrome on Android does for scaling our display of web content, that is use font inflation for desktop pages and plain text zooming for everything else.
Since we don't want to simply clobber any text zoom that might have been set by the user/front-end code, we allow setting and storing the system font scale separately on the PresContext. We then calculate the effective text zoom value as the product of the system font scale and the current text zoom value.
Any function that is using the PresContext's TextZoom value for layouting/rendering is switched over to this new EffectiveTextZoom value, whereas functions that are interested in the text zoom as actually set by the user/front-end (e.g. the nsDocumentViewer, or the code responsible for copying text and full zoom settings into the new PresContext on page navigation) continue using the plain TextZoom value.
As long as font inflation is enabled in principle (e.g. font.size.inflation.minTwips != 0), every page starts out as eligible for font inflation until the relevant meta viewport tags marking the page as "mobile friendly" have been detected. Since the PresShell caches the font inflation state and only recalculates it when necessary, we make use of that and set the PresContext's system font scale as necessary whenever the font inflation state has been refreshed.
MozReview-Commit-ID: 2InyE04wKAW
--HG--
extra : rebase_source : 3f6d7128f37c1dc18f67a6655f86d9a3003fe90b
extra : source : 6100458b97289f9aea5ac8fda57ded045e6860b7
We can remove unnecesasary SMILMappedAttribute and SMILAttrAnimationRuleProcessor since earlier patches in this serieas mean this code is no longer used.
MozReview-Commit-ID: 5Rl5WFW5zZ1
--HG--
extra : rebase_source : cf2efca8d01c7e6cd5bd3b3b44d994c6cbb760e9
This patch removes handling of the 'attributeType' attribute so that we behave
as if attributeType is always 'auto'. This means that for CSS properties we
always animate them as CSS properties (i.e. we animate them as part of the
SMIL override stylesheet) rather than mapped attributes.
The one special case is width/height on an outer SVG. Previously we animated
this as a mapped attribute since Web compatibility requires that the
width/height on an outer SVG, when set explicitly, are mapped to style.
However, we can produce the same behavior by animating these as CSS properties
(as opposed to mapped attributes). There is no observable difference in results
returned by the SVG DOM APIs, only the level at which the result is added to
the cascade: the SMIL override stylesheet instead of the attribute animation
presentation hint level.
As part of this patch, we animate width/height on outer SVG elements as CSS
properties as opposed to mapped attributes both for consistency and also so
we can remove the animated mapped attribute code altogether.
MozReview-Commit-ID: Ll1LWWRQ66R
--HG--
extra : rebase_source : bd513e191e3d0ba2a1e982eea4c548392bf5817d
This changeset will skip finding the first SMIL animation function to affect the sandwich from multiple functions if element hasn't primary frame when composing attributes.
This mean that target element's animation don't need to animate in the following cases.
- ancestor elements has display:none attribute.
- target element have display:none attribute.
- ancestor element's tag produces a non-rendering subtree, by definition (like <desc>).
MozReview-Commit-ID: 253qTpBLc8L
--HG--
extra : rebase_source : c6f0eff440fa5448fc28e5283be68b6e33335b9e
DOM's initEvent says that it must do nothing during dispatch. UI Events
says they behave the same as initEvent, so the legacy initializers
defined there also shouldn't do anything during dispatch. Previously we
only did this for initEvent itself, but other legacy initializers would
function normally during dispatch.
Edge passes the wpt test that's updated in this commit. Chrome passes
all but initCustomEvent. It would be nice to expand the test to have
coverage for all our legacy initializers, but the likelihood of
real-world compat issues from this behavior is slim enough that I didn't
think it was worth the effort.
MozReview-Commit-ID: IYLOuwlPGSj
The surrounding code in this file and elsewhere uses pairs of RangedPtrs
for iterators. While we're trying to modify nsString's iterators so
they're more like RangedPtr, it seems reasonable to go ahead and modify
this instance of nsString iterators to use RangedPtr directly for
conformity with the surrounding code.
Enable nsAttrValue::EnumTable to be initialized with enum. So, we could get rid
of the castings in EnumTable. Fix EnumTable initialization comment.
For those untyped enumerations, declare them with uint8_t, as to other typed
enumerations with type size larger than int16_t, force casting to int16_t.
Use {nullptr,0} instead of {0} to represent the last entry.
MozReview-Commit-ID: 7Dma3Apkmxj
--HG--
extra : rebase_source : b2289866c4c33d80c8e170727bf109d018d92f67
The new name makes the sense of the condition much clearer. E.g. compare:
NS_WARN_IF_FALSE(!rv.Failed());
with:
NS_WARNING_ASSERTION(!rv.Failed());
The new name also makes it clearer that it only has effect in debug builds,
because that's standard for assertions.
--HG--
extra : rebase_source : 886e57a9e433e0cb6ed635cc075b34b7ebf81853
hasFeature() always returning true matches the current DOM spec. SVG 2
has removed requiredFeatures. Chrome has had both of these always
return true since 2014, and they seem to have had no problems.
Even requiredFeatures="" (empty string) now returns true, matching
Chrome.
MozReview-Commit-ID: 1LEu3iK4R94
This patch is generated by the following commands (note: if you're running
using OS X's sed, which accepts slightly different flags, you'll have to
specify an actual backup suffix in -i, or use gsed from Homebrew):
hg stat -c \
| cut -c 3- \
| tr '\n' '\0' \
| xargs -0 -P 8 gsed --follow-symlinks 's/\bnsCSSProperty\b/nsCSSPropertyID/g' -i''
Then:
hg mv layout/style/nsCSSProperty.h layout/style/nsCSSPropertyID.h
... and finally, manually renaming nsCSSProperty in the include guard in
nsCSSProperty.h.
MozReview-Commit-ID: ZV6jyvmLfA
--HG--
rename : layout/style/nsCSSProperty.h => layout/style/nsCSSPropertyID.h
The merge from inbound to central conflicted with the merge from
autoland to central, it appears. Per tree rules, the commit from the
autoland repo wins and the inbound commit gets backed out.
CLOSED TREE
--HG--
extra : amend_source : 927e1cdfa8e55ccbd873d404d905caf6871c8c4f
extra : histedit_source : 07095868c3f767258e1d7d2645193bf4811b13bb%2Ca49ae5a28bf6e67298b6208ee9254c25a2539712
This patch is generated by the following commands (note: if you're running
using OS X's sed, which accepts slightly different flags, you'll have to
specify an actual backup suffix in -i, or use gsed from Homebrew):
hg stat -c \
| cut -c 3- \
| tr '\n' '\0' \
| xargs -0 -P 8 gsed --follow-symlinks 's/\bnsCSSProperty\b/nsCSSPropertyID/g' -i''
Then:
hg mv layout/style/nsCSSProperty.h layout/style/nsCSSPropertyID.h
... and finally, manually renaming nsCSSProperty in the include guard in
nsCSSProperty.h.
MozReview-Commit-ID: ZV6jyvmLfA
--HG--
rename : layout/style/nsCSSProperty.h => layout/style/nsCSSPropertyID.h
This patch makes most Run() declarations in subclasses of nsIRunnable have the
same form: |NS_IMETHOD Run() override|.
As a result of these changes, I had to add |override| to a couple of other
functions to satisfy clang's -Winconsistent-missing-override warning.
--HG--
extra : rebase_source : 815d0018b0b13329bb5698c410f500dddcc3ee12
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
StyleAnimationValue::ComputeValue(s) will automatically look up the style
context of the supplied element. This is mostly fine, but when we start using
this method in scenarios where we are building the initial style context
(as happens later in this patch series) it can easily land us in a situation
where we iterate indefinitely.
It would be better, instead, to just explicitly pass in the style context we
want to use, as we already do for StyleAnimationValue::ExtractComputedValue.
MozReview-Commit-ID: ZoVBlBRRBI
--HG--
extra : rebase_source : 9012cc2e405fc887f070fbfaa2f9853289882862
Now that Declaration implements nsIStyleRule, we don't need the memory
overhead of storing a StyleRule object for style attributes.
We also need to change this prior to patch 5, because the changes in
patch 5 that will allow rules to change (but declarations not) would
otherwise break due to style attribute object merging done by
nsAttrValue::ParseStyleAttribute.
--HG--
extra : commitid : Ij4yRdba7wa
The bulk of this commit was generated with a script, executed at the top
level of a typical source code checkout. The only non-machine-generated
part was modifying MFBT's moz.build to reflect the new naming.
CLOSED TREE makes big refactorings like this a piece of cake.
# The main substitution.
find . -name '*.cpp' -o -name '*.cc' -o -name '*.h' -o -name '*.mm' -o -name '*.idl'| \
xargs perl -p -i -e '
s/nsRefPtr\.h/RefPtr\.h/g; # handle includes
s/nsRefPtr ?</RefPtr</g; # handle declarations and variables
'
# Handle a special friend declaration in gfx/layers/AtomicRefCountedWithFinalize.h.
perl -p -i -e 's/::nsRefPtr;/::RefPtr;/' gfx/layers/AtomicRefCountedWithFinalize.h
# Handle nsRefPtr.h itself, a couple places that define constructors
# from nsRefPtr, and code generators specially. We do this here, rather
# than indiscriminantly s/nsRefPtr/RefPtr/, because that would rename
# things like nsRefPtrHashtable.
perl -p -i -e 's/nsRefPtr/RefPtr/g' \
mfbt/nsRefPtr.h \
xpcom/glue/nsCOMPtr.h \
xpcom/base/OwningNonNull.h \
ipc/ipdl/ipdl/lower.py \
ipc/ipdl/ipdl/builtin.py \
dom/bindings/Codegen.py \
python/lldbutils/lldbutils/utils.py
# In our indiscriminate substitution above, we renamed
# nsRefPtrGetterAddRefs, the class behind getter_AddRefs. Fix that up.
find . -name '*.cpp' -o -name '*.h' -o -name '*.idl' | \
xargs perl -p -i -e 's/nsRefPtrGetterAddRefs/RefPtrGetterAddRefs/g'
if [ -d .git ]; then
git mv mfbt/nsRefPtr.h mfbt/RefPtr.h
else
hg mv mfbt/nsRefPtr.h mfbt/RefPtr.h
fi
--HG--
rename : mfbt/nsRefPtr.h => mfbt/RefPtr.h
Since getFrames() must gather all properties set at a given keyframe
offset time for a given easing function, we need to provide a total
ordering for ComputedTimingFunction objects. Until the spec defines how
to do this, we sort first by NS_STYLE_TRANSITION_TIMING_FUNCTION_*
value, then second by the four values in a cubic-bezier() function (in
order) or the integer and optional keyword in a steps() function.
Because we don't support automatic spacing of keyframes yet,
ComputedKeyFrame.computedOffset is always the same as Keyframe.offset.
Another assumption made is that the value of easing for a Keyframe
object at 100% should be the same as the value from the previous
Keyframe for the same property. An alternative would be to leave off
easing from that Keyframe, which would need the default value for that
IDL dictionary member removed (otherwise it would always be set to
"linear").
Eric Rahm
Brian Birtles
Mantaroh Yoshinaga
Hiroyuki Ikezoe
Bobby Holley
Bevis Tseng
Carsten "Tomcat" Book
Xidorn Quan
Yoshi Huang
Emilio Cobos Álvarez
Josh Matthews
Wes Kocher
Nathan Froyd
Sylvestre Ledru
Robert Longson
Bill McCloskey
Manish Goregaokar
Nazım Can Altınova
Jeremy Chen
Aryeh Gregor
Jan Henning
Florian Quèze
Joel Maher
Cameron McCormack
Sebastian Hengst
Ryan VanderMeulen
Astley Chen
Boris Zbarsky
Andrew McCreight
Boris Chiou
Michael Layzell
Nicholas Nethercote
Hiroyuki Ikezoe
Jonathan Chan
Gregory Szorc
cku
Tom Tromey
Chris Peterson
Jonathan Watt
Daisuke Akatsuka
Olli Pettay
Xidorn Quan
Kyle Huey
Tetsuharu OHZEKI
L. David Baron