Removing them all together because the only non-comm-central consumer is all
the same and this way there's no intermediate state to be maintained there
where we need both the nsINode and the nsIDOMNode.
MozReview-Commit-ID: GDjrroN1jao
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
This fixes a bug where EnsureEventualDidPaintEvent needs to be called separately for each transaction id, but we skip it since mFireAfterPaintEvents is still true from the previous paint.
We now track the equivalent state by checking for the presence of mTransactions[aTransactionId], and correctly schedule an eventual didpaint for each id.
MozReview-Commit-ID: JnRTycGEyom
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : rebase_source : c004a023389f1f6bf3d2f3efe93c13d423b23ccd
dom/time contained the TimeService and TimeManager classes, used for
setting time via Gecko on FirefoxOS. Since FirefoxOS is no longer in
the code base, the directory can be removed.
MozReview-Commit-ID: 8PEk3e6HA67
Currently nsIThreadManager::spinEventLoopUntil doesn't monitor the shutting
down. Firefox shutting down can be blocked by a 'broken' use of
nsIThreadManager::spinEventLoopUntil.
nsIThreadManager::spinEventLoopUntilOrShutdown should be used instead.
So that we can now ensure nsRefreshDriver ticks (i.e. nsRefreshDriver doesn't
stop its timer) for all queued events.
Before this patch, dispatching CSS animation/transition events relied on the
fact that DocumentTimeline observes nsRefreshDriver. For this fact,
animationcancel or transitioncancel event did not dispatch properly in some
cases, i.e. the case where the animation was dropped from the DocumentTimeline.
MozReview-Commit-ID: 7JYro0MY2U2
--HG--
extra : rebase_source : 28c8e2a50d29c5344e2c5ca3c43af41f4692fa0f
Now we sort CSS animation/transition events by scheduled event time prior
to compositor order.
SortEvents() will be a private method in the next patch in this patch
series.
MozReview-Commit-ID: ICkOayquN0f
--HG--
extra : rebase_source : 405c8232e93c54a073c722a4332873af02daa870
In a subsequent patch in this patch series, we want to make nsPresContext
have an AnimationEventDispatcher as RefPtr<>.
Instead, if we were trying to make nsPresContext have the
AnimationEventDispatcher as data object (not RefPtr<>) just like we did in
CommonAnimationManager, we will fall into header inclusion hell since Element.h
includes nsPresContext.h and AnimationEventDispatcher.h ends up including
Element.h. Even if we could solve the inclusion hell, we will suffer from Rust
bindgen issues for some reasons.
MozReview-Commit-ID: B0nX2JzIRJD
--HG--
extra : rebase_source : 4eb998876b2fc39de8d09cac09c19e1a51cd382e
Now single AnimationEventDispatcher can handle both CSS animation/transition
events simultaneously. To do this we had to change AnimationEventInfo and
TransitionEventInfo into a single struct, the struct is also named
AnimationEventInfo.
It results we can sort both CSS animation/transition events altogether. Thus
we make sure CSS animation/transition events are sorted by scheduled event time
prior to their composite order (i.e. transitions is prior to animations).
At this moment, we don't sort both events altogether since nsAnimationManager
and nsTransitionManager has an AnimationEventDispatcher respectively. In the
next patch we move AnimationEventDispatcher into nsPresContext, i.e. each
document has an AnimationEventDispatcher without the distinction between
CSS animations and transitions.
Note that, after this patch, we copy all members in InternalTransitionEvent and
InternalAnimationEvent in the copy-constructor of AnimationEventInfo, this
will be fixed once WidgetEvent has move-constructor and move-assignment
(bug 1433008).
MozReview-Commit-ID: 5JAh6N7C6ee
--HG--
extra : rebase_source : 50da76f51cf65cdd1245d93d8b48aaf0ae0ec94b
We plan to use this class to dispatch web animation API events as well
(bug 1354501).
MozReview-Commit-ID: 7DMmc0aJzJ5
--HG--
extra : rebase_source : 445428771238ad31697cede8afbab35c1144a422
The comment is no longer correct since bug 1180125.
MozReview-Commit-ID: A4NWgmwAOFt
--HG--
extra : rebase_source : 57471f99bcbef86bf211692eee8cf06513f4b60a
It's not need to be a template function since the function is independent from
AnimationType.
MozReview-Commit-ID: 13WkRIfaQbZ
--HG--
extra : rebase_source : 5df3eb22dc2785b43718f388a9a32915a18c8be2
We just need information whether there is still an observer or not in most
cases. The only case we need to know the count is in an assertion in the
dtor of nsRefreshDriver. In the dtor we are checking there remains no
observers other than early runners.
Note that the order in HasObserver() was adjusted to reflect that we check
boolean flag first (mViewManagerFlushIsPending) and subsequently check observer
which is likey happen to. mFrameRequestCallbackDocs should have checked prior
to mResizeEventFlushObservers though.
MozReview-Commit-ID: E1qplusqw1Y
--HG--
extra : rebase_source : ebd9e6eb08952df954c55860638233c9a8729856
The selectorText test happens to pass right now because well, we don't implement
the setter yet[1], but would fail if we implemented an specific invalidation in
the way I'd have done it yesterday.
[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=37468
MozReview-Commit-ID: DrMTgLzQcnk
dom/time contained the TimeService and TimeManager classes, used for
setting time via Gecko on FirefoxOS. Since FirefoxOS is no longer in
the code base, the directory can be removed.
MozReview-Commit-ID: 8PEk3e6HA67
--HG--
extra : rebase_source : 63a0a6c665792ab1885bd4f81261db9be887ffd1
We don't need to collect whole descendants documents.
This patch intentionally leaves animation events handling which is another
caller of CollectDocuments in nsRefreshDriver since the animation part will
be fixed in a different way in bug 1415780.
MozReview-Commit-ID: INAJm1NHLuI
--HG--
extra : rebase_source : 4e255cef604d4455d6efa5dc2ebddd5dc649ee65
We do this by tracking them as a property on the root frame the same way we do for modified frames.
We also set the property in ProcessFrame but that is okay because we are guaranteed to finish the partial update at that point.
This is a minimal version of the recaptcha popup that was one of the
ways to observe the bug.
MozReview-Commit-ID: JUhw9IkH0Tm
--HG--
extra : rebase_source : a7f15ead1a919f4d66a72b9732c31b1bcfe41678
