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).
Without this, we will start including mozMemory in performance.toJSON() even if
the pref for it is not set, once 'object' becomes a JSON type.
This changes behavior in the following observable ways:
1) We stop exposing PerformanceResourceTiming's .serverTiming in the JSON
serialization in insecure contexts.
2) We stop exposing PerformanceTiming's timeToNonBlankPaint and
timeToDOMContentFlushed in the JSON serialization unless the relevant
preferences are turned on.
This changes semantics in all sorts of ways (e.g. now we get the right proto
from our |this| value instead of it being baked into the function). But if all
our chrome callers are well-behaved this should be ok.
We _could_ bake the proto id and depth into the function itself by using
js::NewFunctionWithReserved if it were not for Xrays. Those already need the
reserved slots on functions we Xray.
MozReview-Commit-ID: 1bYrKWWIc1P
Right now we do this check pretty much always anyway for isInstance... we do it
twice for anything that actually has [ChromeOnly] bits.
MozReview-Commit-ID: FHbYED4FPJe
The codegen changes are mostly a backout of the changes made in bug 1274159.
The HTMLConstructor implementation is mostly copied from one of the
code-generated ones, with a few modifications:
* Derive the interface name from the proto id instead of hardcoding it.
* Use the proto/constructor ids to get constructor and prototype objects.
* Use ErrorResult instead of FastErrorResult; we don't want the precedent of
using FastErrorResult in non-generated code.
There will be further changes to combine HTMLConstructor and
CreateXULOrHTMLElement, in a separate changeset.
MozReview-Commit-ID: 44D0qw23ioP
This allows custom elements to work in any document in the parent process that
allows XUL and XBL. The test takes the easy option of moving the existing XUL
custom element test to a run with the custom element pref disabled.
MozReview-Commit-ID: CMiLzmp60jA
--HG--
extra : rebase_source : 735688061116c633b816f4f9d488712408df11a5
extra : source : 794ee6857d83dfe0b18629c12e96a622fc899586
This allows custom elements to work in any document in the parent process that
allows XUL and XBL. The test takes the easy option of moving the existing XUL
custom element test to a run with the custom element pref disabled.
MozReview-Commit-ID: CMiLzmp60jA
--HG--
extra : rebase_source : b9632de82cf79c1df15be09fadf1d25817c8a894
extra : amend_source : 235a76453d1d6782903d5051ee8e234b965dcc36
This way we don't include it in all the binding headers. We only need
jsfriendapi.h for the static_asserts involving JSJitInfo, so we move those to
PrototypeList.cpp.
MozReview-Commit-ID: 7KOmbjwSBOD
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.
