Web-visible WebIDL interfaces require DOM peer review with every change, which
is enforced by a commit hook. ChromeOnly interfaces are not exposed to the
web, and therefore don't require the same strictures.
The current commit hook enforces the review requirement for changes to any
(non-Servo) WebIDL file, and is not smart enough to determine if the change is
web-visible. In order to loosen that restriction, we need the build system to
enforce the requirement that only WebIDL files in certain locations may
contain web-visible interfaces, so that the commit hook can restrict itself to
checking only those directories.
This change restricts the location of web-visible WebIDL interfaces to the
dom/webidl/ and dom/bindings/ roots (along with the corresponding objdir root
for generated interfaces). A follow-up will change the commit hook to only
enforce review requirements on these directories.
MozReview-Commit-ID: CiDxXxN4oO4
--HG--
extra : rebase_source : d836004da9f2def74e7c8cd5d580db2290a938d4
extra : intermediate-source : 608e21fcd1674dae3f8b685cedab85c43ffdb485
extra : source : 6cb20ada1a0aa1f6d621ba3c85ce9946a6f9841f
Web-visible WebIDL interfaces require DOM peer review with every change, which
is enforced by a commit hook. ChromeOnly interfaces are not exposed to the
web, and therefore don't require the same strictures.
The current commit hook enforces the review requirement for changes to any
(non-Servo) WebIDL file, and is not smart enough to determine if the change is
web-visible. In order to loosen that restriction, we need the build system to
enforce the requirement that only WebIDL files in certain locations may
contain web-visible interfaces, so that the commit hook can restrict itself to
checking only those directories.
This change restricts the location of web-visible WebIDL interfaces to the
dom/webidl/ and dom/bindings/ roots (along with the corresponding objdir root
for generated interfaces). A follow-up will change the commit hook to only
enforce review requirements on these directories.
MozReview-Commit-ID: CiDxXxN4oO4
--HG--
extra : source : 6cb20ada1a0aa1f6d621ba3c85ce9946a6f9841f
extra : histedit_source : 1f02888264a936db3e77134c0a7203e911707312%2C6ea38c077b8a7dfaf358bc819d150a20db9bd6b7
Web-visible WebIDL interfaces require DOM peer review with every change, which
is enforced by a commit hook. ChromeOnly interfaces are not exposed to the
web, and therefore don't require the same strictures.
The current commit hook enforces the review requirement for changes to any
(non-Servo) WebIDL file, and is not smart enough to determine if the change is
web-visible. In order to loosen that restriction, we need the build system to
enforce the requirement that only WebIDL files in certain locations may
contain web-visible interfaces, so that the commit hook can restrict itself to
checking only those directories.
This change restricts the location of web-visible WebIDL interfaces to the
dom/webidl/ and dom/bindings/ roots (along with the corresponding objdir root
for generated interfaces). A follow-up will change the commit hook to only
enforce review requirements on these directories.
MozReview-Commit-ID: CiDxXxN4oO4
--HG--
extra : rebase_source : f61b33ae4c973b1c9ec1423bb9baca59725e44b1
The change in browser_net_view-source-debugger.js is needed because we now use WebIDL callbacks for MessageListener, and they add async creation stack frames.
--HG--
extra : rebase_source : d7c026d8a77634ef2566feba78168beb8a66a552
The change in browser_net_view-source-debugger.js is needed because we now use WebIDL callbacks for MessageListener, and they add async creation stack frames.
--HG--
extra : rebase_source : 77672a73a6e1447c763930143116a261f2369e67
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.
I looked at the diff in the generated code, and the only change is that
SpeechRecognitionEvent's unlink impl goes from:
NS_IMPL_CYCLE_COLLECTION_UNLINK_BEGIN_INHERITED(SpeechRecognitionEvent, Event)
NS_IMPL_CYCLE_COLLECTION_UNLINK(mResults)
tmp->mInterpretation.setUndefined();
NS_IMPL_CYCLE_COLLECTION_UNLINK(mEmma)
NS_IMPL_CYCLE_COLLECTION_UNLINK_END
to:
NS_IMPL_CYCLE_COLLECTION_UNLINK_BEGIN_INHERITED(SpeechRecognitionEvent, Event)
NS_IMPL_CYCLE_COLLECTION_UNLINK(mResults)
NS_IMPL_CYCLE_COLLECTION_UNLINK(mEmma)
+ tmp->mInterpretation.setUndefined();
NS_IMPL_CYCLE_COLLECTION_UNLINK_END
MozReview-Commit-ID: FISIphljlT6
These are cases that are implementing the "convert an exception to a Promise"
steps of the Web IDL spec. Typically the exception is thrown in the current
compartment; the Promise returned should simply match that. Otherwise we can
end up with a situation in which the promise doesn't actaully have access to
its rejection value, which will cause problems if someone uses then() on the
promise: the return value of the then() call will get a sanitized exception
instead of the real one.
We _could_ try to match the actual compartment of the exception, in theory.
But it's not clear why this would be preferable to using the current
compartment, even if there were cases in which the exception _doesn't_ match
the current compartment. Which there likely are not.
MozReview-Commit-ID: Ac2BHIHxfvY
--HG--
rename : dom/promise/tests/test_promise_argument.html => dom/promise/tests/test_promise_retval.html
rename : dom/promise/tests/test_promise_argument_xrays.html => dom/promise/tests/test_promise_retval_xrays.html
We currently don't generate a ::ToJSON() method for WebIDL types with record<K,V>
members. These types should be safe to convert to JSON, as long as type V itself
is. Per spec, type K is always a DOMString, USVString, or ByteString.
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <