We want to have some class names with spaces in them, but everything assumes
that an interface identifier is in fact an identifier (e.g. uses it in C++
identifiers like namespace names).
Compared to the spec, we had the following differences:
* Date was a JSON type in our implementation. It doesn't even exist as a type
in the spec. It stops being a JSON type.
* Annotated types are not supported yet. Nothing changes here.
* Typedef types were not JSON types in our implementation. They become JSON
types if the type it's a typedef for is one.
* Frozen arrays are not supported yet. nothing changes here.
* Records were not JSON types in our implementation. They become JSON types
when the value type is a JSON type.
* Object was not a JSON type in our implementation. It becomes a JSON type.
* Interface types were only JSON types in our implementation if they had a
jsonifier. We change to treating them as JSON types if there is a jsonifier
anywhere on the inheritance chain.
In terms of observable behavior, the following properties now get included by
toJSON methods that didn't use to be included:
PaymentResponse.details
Performance.mozMemory
both because they're of type "object".
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.
As opposed to Alias attribute, which reuses the JS function object for the property, BindingAlias will only reuse the generated attribute binding implementation, without changing observable behavior. It can be used to reduce amount of generated code, if the attributes are known to behave exactly the same.
This cuts the size of generated CSS2PropertiesBinding.cpp by half, and removes ~100kB of dupicated code from libxul.
MozReview-Commit-ID: G0q8TbaqFdp
--HG--
extra : rebase_source : 87a2a501cc8adb379df1f4563d3696a339abd0fc
When defining WebIDL constants in C++, we may need to undefine some
constant names that conflict with windows.h preprocessor defines.
Doing this in the binding header is far easier than tracking down the
include orders that may cause conflicts.
MozReview-Commit-ID: A0UoYezIQs5
--HG--
extra : rebase_source : d9100af2ccdb5c6e6468542ac68f74b2e4f9050c
This test suite involves a bunch of python tests which don't require
configure or any generated binaries to run. We can split them out into a
Taskcluster linter type task to run directly on the source tree in
parallel with builds.
MozReview-Commit-ID: 9ux3rAuFXAY
--HG--
extra : rebase_source : 95378cd686644e34ea017c682d7384906b17d13a
