For review purposes, the important changes are in dom/bindings/Configuration.py
and dom/bindings/parser.
The changes to the IDL files were done by running these in dom/webidl
and dom/bindings/test:
perl -pi -e 's/^interface ([A-Za-z0-9_]+)($| [:{])/[Exposed=Window]\ninterface \1\2/' *.webidl
perl -pi -e 'BEGIN { $/ = undef; } s/\[HTMLConstructor\]\n\[Exposed=Window\]/[HTMLConstructor,\n Exposed=Window]/g' *.webidl
perl -pi -e 'BEGIN { $/ = undef; } s/\[NoInterfaceObject\]\n\[Exposed=Window\]/[NoInterfaceObject,\n Exposed=Window]/g' *.webidl
perl -pi -e 'BEGIN { $/ = undef; } s/\[ChromeOnly\]\n\[Exposed=Window\]/[ChromeOnly,\n Exposed=Window]/g' *.webidl
And running this in dom/chrome-webidl:
perl -pi -e 'BEGIN { $/ = undef; } s/\[ChromeOnly\]\ninterface/[ChromeOnly, Exposed=Window]\ninterface/g' *.webidl
and then fixing all the resulting parser failures. I then verified that the
generated code is the same as before this change.
Differential Revision: https://phabricator.services.mozilla.com/D46697
--HG--
extra : moz-landing-system : lando
`= {}` can now be used to indicate that an optional dictionary should have the
default value of 'default-initialized dictionary'
Differential Revision: https://phabricator.services.mozilla.com/D36504
--HG--
extra : moz-landing-system : lando
`= {}` can now be used to indicate that an optional dictionary should have the
default value of 'default-initialized dictionary'
Differential Revision: https://phabricator.services.mozilla.com/D36504
--HG--
extra : moz-landing-system : lando
`= {}` can now be used to indicate that an optional dictionary should have the
default value of 'default-initialized dictionary'
Differential Revision: https://phabricator.services.mozilla.com/D36504
--HG--
extra : moz-landing-system : lando
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
This patch was generated by my modeline.py script.
MozReview-Commit-ID: EbVjPLwiUAT
Depends on D4159
Differential Revision: https://phabricator.services.mozilla.com/D4161
--HG--
extra : moz-landing-system : lando
This feature should not be shipped until the various definitions of addition for
each additive property are properly specified.
Unlike other patches in this series, compositing is not frequently used
internally (e.g. by DevTools etc.) so there is no need to enable this by default
for system code.
Also, it turns out we have inadvertently been shipping part of this feature for
some time now. The next patch in this series will add tests for that case and
disable that part of the feature (a suitable intent to unship will follow). This
patch merely adapts and extends the existing tests without affecting the surface
area covered by the combination of the newly-added pref and the existing
dom.animations-api.core.enabled pref.
MozReview-Commit-ID: Htr6mlyCBav
--HG--
rename : dom/animation/test/mozilla/file_disable_animations_api_core.html => dom/animation/test/mozilla/file_disable_animations_api_compositing.html
rename : dom/animation/test/mozilla/test_disable_animations_api_core.html => dom/animation/test/mozilla/test_disable_animations_api_compositing.html
extra : rebase_source : 7715a25e59568eb122ba3f7dbd2c2b2ffdd19954
By doing this we will have all the KeyframeEffect* related code in
KeyframeEffectReadOnly.{h,cpp} so we can rename them to KeyframeEffect.{h,cpp}
in the next patch and make it easier to examine the history for the bulk of this
code.
The added [HeaderFile] annotation will be removed in a subsequent patch in this
series.
MozReview-Commit-ID: Fxk6fPukgAS
--HG--
extra : rebase_source : 0bb0f846aba69e2b79724adb3148948317667eae
It might seem a bit odd to move the setters to the read-only class that we are
ultimately planning to drop but the reason for doing this is that
KeyframeEffectReadOnly.cpp has a *lot* more code than KeyframeEffect.cpp.
In order to simplify code archaeology we take the following approach:
1. Move code from KeyframeEffect.{h,cpp} to KeyframeEffectReadOnly.{h,cpp}.
2. Delete KeyframeEffect.{h,cpp}.
3. Rename KeyframeEffectReadOnly.{h,cpp} to KeyframeEffect.{h,cpp}.
Note that at least steps 2 and 3 must be performed in separate patches as
mercurial does not successfully track renames when the target name already
exists.
MozReview-Commit-ID: LwJoxGJitKR
--HG--
extra : rebase_source : ae437c6e74435b983c7390df301055472fa3c4ff
KeyframeEffect and KeyframeEffectReadOnly constructors can run in the caller
compartment, which is okay because the current compartment is used in the
following places and all of them are safe:
1. GlobalObject::CallerType(), that is ultimately passed to
nsDocument::IsWebAnimationsEnabled in KeyframeEffectParamsFromUnion,
to decide whether to copy mIterationComposite/mComposite to
KeyframeEffectParams.
GlobalObject::CallerType() can now be different than the target window's one,
if the caller has the system principal and the target is web content, and
in that case nsDocument::IsWebAnimationsEnabled there always returns true
while Web Animations can be disabled on web content.
honoring the mIterationComposite/mComposite properties is OK, since it just
changes the animation behavior, and this is disabled by default until
remaining spec issues are resolved.
2. GlobalObject::Context(), that is ultimately passed to
KeyframeUtils::GetKeyframesFromObject and used while extracting information
from passed-in keyframe object, with iterable/iterator protocols.
Performing that operation in the caller side is okay, since the same thing
can be done on caller, and the operation doesn't perform any GCThing
allocation on the target window global.
KeyframeEffect and KeyframeEffectReadOnly constructors can run in the caller
compartment, which is okay because of the following reasons:
1. The target window global is used for most operation:
* KeyframeEffectReadOnly::ConstructKeyframeEffect uses the target window
global instead of current global.
* KeyframeEffectParamsFromUnion which receives `aGlobal.CallerType()`
In Xray case, Web Animations API can be disabled on web content
(currently disabled on beta/release by default), and in that case some API
won't work even it's triggered from WebExtensions, but it should be fine.
2. GetKeyframesFromObject is executed in the caller's compartment to access
the passed-in JSObject that is keyframe, with iterable/iterator protocols.
This operation doesn't perform any GCThing allocation on the target window
global.
In bug 1241783 and Github issue #186[1] it was decided to update the WebIDL in
the Web Animations spec so that instead of using a mixin as the type, we instead
use a suitable union type.
This patch removes the comments that indicated that the Gecko WebIDL definition
need to be updated to match the spec, since the spec has now been updated to
match the Gecko WebIDL definition instead.[2]
[1] https://github.com/w3c/web-animations/issues/186
[2] a07f609270d0445d2a46
Use [SetterThrows] for KeyframeEffect.spacing because it throws if the input
string is not conformed to the grammar.
MozReview-Commit-ID: CkAnPu8TnV
--HG--
extra : rebase_source : af0960391684323a25ac0b40da28dcbe5c3c2919
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
At the same time we also make the 'warning' member of AnimationPropertyDetails
no longer nullable and simply use the absence of the member to indicate "no
warning" (which is what we were already doing -- we were never actually setting
it to null).
MozReview-Commit-ID: HdRDbqhCdmw
--HG--
extra : rebase_source : 0282bd9f0e213aa0e1ed1f5b25d58b10fb3dbc0b
extra : histedit_source : 7d1f81dc57e2a55ab0ed6c4919a25b87819d9d58
We are now extending this API to include more than just metadata about each
animated property but also the property values themselves.
Note that we can't use the name AnimationProperty for the dictionary since
we already use that name internally and [BinaryName] doesn't seem to apply to
dictionaries.
MozReview-Commit-ID: AcXeN4fsgTz
--HG--
extra : rebase_source : 714fdf85484775244daad6aaa288b1ec73ad6793
Add KeyframeEffectOptions in KeyframeEffect.webidl
--HG--
extra : rebase_source : 1d85d91614f7788b42105e32c043e9e9851d48ba
extra : amend_source : acbe1dee541e21df9b9409dbdab9ddc092186564
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").
Boris Zbarsky
Cosmin Sabou
Mihai Alexandru Michis
Brian Birtles
Emilio Cobos Álvarez
Andrew McCreight
Tooru Fujisawa
Boris Chiou
Hiroyuki Ikezoe
Ryo Kato
Ryo Motozawa
Cameron McCormack
Carsten "Tomcat" Book