The stack object might be a CCW and we want to make it impossible to get a CCW's global. Now the caller has to supply a same-compartment global object, so we no longer rely on getting the CCW's global.
Summary:
This fixes a couple fuzz bugs and prevents special-casing <svg:use> even more in
bug 1431255.
Unfortunately not as many hacks went away as I'd have hoped, since we still need
to match document rules, see the linked SVGWG issues.
But blocks_ancestor_combinators goes away, which is nice since it's on a very
hot path.
Test Plan: WPT for style invalidation, covered by existing tests otherwise.
Reviewers: heycam
Tags: #secure-revision
Bug #: 1450250
Differential Revision: https://phabricator.services.mozilla.com/D2154
MozReview-Commit-ID: C4mthjoSNFh
Right now consumers can't know when the parent process has finished talking
to the permission manager. It would be nice to enable consumers to depend
on the status of the asynchronous task using a promise.
Right now consumers can't know when the parent process has finished talking
to the permission manager. It would be nice to enable consumers to depend
on the status of the asynchronous task using a promise.
Thought I had to update this as well, but nope. When basically any style changes
we already update transitions.
needs_transitions_update already handles the physical mapping changing by
checking whether any transition for the physical property remain there or not.
MozReview-Commit-ID: 6vKwal4yzRU
This is probably the last thing we will ship since it needs the most spec work.
MozReview-Commit-ID: LLmDBLCsCBJ
--HG--
extra : rebase_source : c06752c9201a9ede87e1ac200ab12577bf784ce6
This preference controls whether authors are allowed to specify animations
without a 0% or 100% keyframe.
We intend to ship this soon but this preference acts as a safeguard in case we
discover we need to disable it.
This feature is very convenient and commonly used so this patch ensures it is
always enabled for system content.
MozReview-Commit-ID: BHTsuS2xO61
--HG--
rename : dom/animation/test/mozilla/file_disable_animations_api_core.html => dom/animation/test/mozilla/file_disable_animations_api_implicit_keyframes.html
rename : dom/animation/test/mozilla/test_disable_animations_api_core.html => dom/animation/test/mozilla/test_disable_animations_api_implicit_keyframes.html
extra : rebase_source : 04fd93dd26a4765c14b0b22febdb0311b650ea59
We don't intend to ship this in the near future until the integration with
AnimationWorklet is clear (although we might ship a read-only version).
That said, we use this feature extensively internally (e.g. in DevTools etc.) so
we enable this feature for system callers.
MozReview-Commit-ID: AhB7ZmU1Xzw
--HG--
extra : rebase_source : 630d7dc56b44a9261bb34aa5417cb9b7050efba4
I also tried to avoid this change but, again, given the number of times I was
repeating the same pattern of defining a static method just to forward a
callback to an instance method, decided it was probably necessary. Without an
easy way to do this, people are more likely to register observers rather than
callbacks, for which we'll wind up paying a continued memory and performance
penalty.
This patch adds a helper which creates a type-safe preference callback
function which forwards calls to an instance method on its closure object.
The implementation is somewhat complicated, mainly due to the constraint that
unregistering a callback requires passing the exact same function pointer that
was used to register it. The patch achieves this by creating the callback
function as a template, with the method pointer as a template parameter. As
long as the Register and Unregister calls happen in the same translation unit,
the same template instance is guaranteed to be used for both.
The main difficulty is that, until C++ 17, there's no way match a value as a
template parameter unless you know its complete type, or can at least compute
its complete type based on earlier template parameters. That means that we
need a macro to extract the type of the method, and construct the template
with the full set of explicit parameters.
MozReview-Commit-ID: 10N3R2SRtPc
--HG--
extra : rebase_source : 7d0a8ddeb77e01d4a6f421459514e93bc0875598
I initially tried to avoid this, but decided it was necessary given the number
of times I had to repeat the same pattern of casting a variable to void*, and
then casting it back in a part of code far distant from the original type.
This changes our preference callback registration functions to match the type
of the callback's closure argument to the actual type of the closure pointer
passed, and then casting it to the type of our generic callback function. This
ensures that the callback function always gets an argument of the type it's
actually expecting without adding any additional runtime memory or
QueryInterface overhead for tracking it.
MozReview-Commit-ID: 9tLKBe10ddP
--HG--
extra : rebase_source : 7524fa8dcd5585f5a31fdeb37d95714f1bb94922
This way we reuse the same machinery everywhere for the content property.
The only difference is that we need to look at the parent style for content
instead of just our style, and at a given index.
Again, this is fine because changing content reframes, so no chance to mess up.
This allows the generated content stuff to not implement nsImageLoadingContent
and all that stuff, nor deal with events, which makes it much simpler IMO.
Now it just tracks an index. We may not even need for it to be an HTML element,
but I've kept that for now.
I added a crashtest that used to crash because of the bogus
nsCSSFrameConstructor code which trusted the node name without checking it was
native anonymous.
Differential Revision: https://phabricator.services.mozilla.com/D1897
MozReview-Commit-ID: 1pAzIvRRVnL
This way we reuse the same machinery everywhere for the content property.
The only difference is that we need to look at the parent style for content
instead of just our style, and at a given index.
Again, this is fine because changing content reframes, so no chance to mess up.
This allows the generated content stuff to not implement nsImageLoadingContent
and all that stuff, nor deal with events, which makes it much simpler IMO.
Now it just tracks an index. We may not even need for it to be an HTML element,
but I've kept that for now.
I added a crashtest that used to crash because of the bogus
nsCSSFrameConstructor code which trusted the node name without checking it was
native anonymous.
Differential Revision: https://phabricator.services.mozilla.com/D1897
MozReview-Commit-ID: 1pAzIvRRVnL
Key of TextCompositionArrary to search composition on widget is native IME
context. However, if TextInputProcessor dispatches composition events via
TextEventDispatcher, TextEventDispatcher::InitEvent() sets native IME context
of dispatching composition events to pseudo IME context (that's raw pointer
of TextEventDispatcher and process ID).
IMEStateManager::DispatchCompositionEvent() looks for existing TextComposition
with native IME context stored in WidgetCompositionEvent before dispatching
an event. However, after dispatching it, it looks for remaining TextComposition
instance with widget stored in WidgetCompositionEvent. Then,
TextCompositionArrary::IndexOf(nsIWidget*) will look for an instance with
the result of nsIWidget::GetNativeIMEContext() and this never returns actual
native IME context. Therefore, IMEStateManager::DispatchCompositionEvent()
always fails to remove TextComposition instance from the array even after
a test composition is finished.
This patch moves nsIWidget::GetNativeIMEContext() to nsBaseWidget to refer
nsBaseWidget::mTextEventDispatcher makes it return pseudo IME context if
TextInputProcessor has input transaction. Therefore, IMEStateManager becomes
always removes TextComposition from the array when every composition ends.
MozReview-Commit-ID: H1PCtPjBYJR
--HG--
extra : rebase_source : cbb3f3aae9954d65135d3840be8974fa30c4f7ff