Bugzilla

Sometimes we call EnsureTimerStarted from within a refresh tick. In some cases, this can schedule an extra tick even though all the necessary flushes will already happen during a later phase of the current tick.

For example: In a refresh tick, scroll events are fired before Styles are flushed. If, during the scroll event, style is changed, we know that those changes will be picked up by the style flush later in this tick.
But instead, we play it safe and schedule another tick after the current one.
This is usually harmless, but it will make a difference when we have bug 1675614: If no extra tick is scheduled, the next paint can be an early paint, and we have an opportunity for lower latency.

Testcase: attachment 8667908 [details]
Profile: https://share.firefox.dev/3k0ko0X
When you hover the RefreshDriverTick markers, you can see the cause callstacks. They show that the first tick was caused by the RequestContentRepaint IPC message, and the second tick was caused by a change to the backgroundPosition property, which happened inside the scroll event listener during the first tick.

To fix this, we should add an argument to EnsureTimerStarted with the needed refresh driver phase, and not schedule a tick if we're currently inside a refresh tick and the needed phase is still upcoming.

Sometimes we call [EnsureTimerStarted](https://searchfox.org/mozilla-central/rev/96e2c6e14998f38e419850d55d8a3d32a3fc244a/layout/base/nsRefreshDriver.cpp#1431) from within a refresh tick. In some cases, this can schedule an extra tick even though all the necessary flushes will already happen during a later phase of the current tick.

For example: In a refresh tick, scroll events are fired before Styles are flushed. If, during the scroll event, style is changed, we know that those changes will be picked up by the style flush later in this tick.
But instead, we play it safe and schedule another tick after the current one.
Requesting extra ticks is usually harmless, but it will make a difference when we have bug 1675614: If no extra tick is requested, the next tick can be an early tick, and we have an opportunity for lower latency.

Testcase: attachment 8667908 [details]
Profile: https://share.firefox.dev/3k0ko0X
When you hover the RefreshDriverTick markers, you can see the cause callstacks. They show that the first tick was caused by the RequestContentRepaint IPC message, and the second tick was caused by a change to the backgroundPosition property, which happened inside the scroll event listener during the first tick.

To fix this, we should add an argument to EnsureTimerStarted with the needed refresh driver phase, and not schedule a tick if we're currently inside a refresh tick and the needed phase is still upcoming.