If we run following code, content process will crash.
------
anim1.timeline = timeline;
anim2.timeline = document.timeline;
anim2.timeline = timeline;
------
The AnimationTimeline has LinkedList variant. (called mAnimationOrder) And Animation is sub-class of LinkedListElement.
We will create the relationship of AnimationTimeline and Animation when calling the AnimationTimeline::NotifyAnimationUpdated. However we didn't remove these relation ship when setting new timeline.
So we should remove these relationship when setting new timeline object.
MozReview-Commit-ID: RDyranduTA
--HG--
extra : rebase_source : 1f080ad80f258162e94f80470a7464e2a9bb033b
This is implementation of 'Setting the timeline of an animation'.[1]
[1] https://w3c.github.io/web-animations/#setting-the-timeline
MozReview-Commit-ID: A5YMXhkxHjr
--HG--
extra : rebase_source : 73e4fdc9ee98bf756267a05a2336a2c51517cf34
ResetDecode was disconnecting mAudioDataRequest when seeking video
only. This means that, if a RequestAudioData() was outstanding,
mAudioDataRequest and MFR.mAudio.mHasPromise would become out-of-sync.
MozReview-Commit-ID: EaS5NERsxpt
PuppetWidget::GetInputContext() needs to communicate with its parent process with synchronous IPC. This is very expensive for focus move.
Currently, IMEStateManager uses nsIWidget::GetInputContext() only for checking the IME enabled state. Therefore, it's enough to cache input context when nsIWidget::SetInputContext() is called. Then, we can avoid to communicate with synchronous IPC with PuppetWidget::GetInputContext() in most cases.
This patch makes IMEStateManager stores the last widget which sets input context. When PuppetWidget uses its input context cache, it should check if it is the last widget to set input context with IMEStateManager since an input context may be shared with other widgets and another one may have update the input context. I.e., PuppetWidget's input context cache may be already outdated after IMEStateManager sets input context with another widget.
This patch gives up to support retrieving IME open state from child process. However, perhaps, this is not necessary for everybody including add-on developers because the only user of IME open state in child process is nsIDOMWindowUtils. So, add-ons can send IME open state from chrome process instead. If this decision is wrong, unfortunately, we should support it again in another bug. It's easy to support with creating another nsIWidget::GetInputContext() or adding additional argument to it.
MozReview-Commit-ID: B2d2CCTsPKj
--HG--
extra : rebase_source : 4117330ba7871753176da960063b612e96f11752
By perfect-forwarding its argument, we can automatically gain move semantics
optimization when storing the given function object into nsRunnableFunction.
Also it allows movable-only function objects.
MozReview-Commit-ID: 9EZK84ZhMvR
--HG--
extra : rebase_source : 9ec11f728d69d4b032d9ba4263241832030b383a
