Bug 297596 – “Infinite” CSS animation durations render page unresponsive

• Status: RESOLVED
• Resolution: FIXED
• Component: Animations

[Eric Meyer]

Given the following CSS applied to a single <div>:

div {
	animation-name: spin;
	animation-duration: calc(infinity * 1s);
}
@keyframes spin {
	from {
		transform: translateX(0);
	}
	to {
		transform: translateX(100px);
	}
}


…the page is rendered, but becomes effectively unresponsive.

• The browser window can be dragged around the screen, and closed with either mouse or keyboard commands, without apparent lag.
• The page can be scrolled without apparent lag if the content is tall enough to trigger a scrollbar, but the layout is frozen at its initial paint state.
• Resizing the browser window will leave the vertical scrollbar in its initial spot, even if the window is made wider or narrower.
• If not already open at page load, the only way to open the Web Inspector is via the Develop menu.  Once it is open, the Elements tab will either be incomplete or completely empty.
• Contextual menus do not appear, and interactions (including drag-selection of page text) are ignored; indeed, the mouse cursor does not change from a pointer to an I-bar when hovering over text content.
• Some attempts to interact with the browser viewport trigger a brief SBBoD, but more often have no visible effect.

Firefox and Chrome will both render the above while remaining fully responsive.  They do not, of course, show any visible animation, given that the time to complete it would be somewhere around ten times longer than the time at which almost all matter in the universe will have been swallowed by supermassive black holes, or else half again as long as the highest estimate of the time it will take for all nucleons in the observable universe to decay.  (Source: Wikipedia’s “Timeline of the far future” page.)

[Radar WebKit Bug Importer]

<rdar://problem/158775366>

[Antoine Quint]

Created attachment 476465 [details]
Testcase

Attached a test case which shows that using a non-accelerated animation also shows the issue.

[Antoine Quint]

The Web process is pegged at 100% CPU usage, we appear to be hung in `UnitBezier::sampleCurveX()`. This all stems from the `epsilon` value computed in `TimingFunction::transformProgress()`:

        auto epsilon = 1.0 / (1000.0 * duration);

We should introduce a cap here to not deal with infinitely small values.

[Antoine Quint]

This can be worked around by using `animation-timing-function: linear`. This shows that the animation-duration computes to 179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368s.

[Antoine Quint]

Pull request: https://github.com/WebKit/WebKit/pull/49660

[Antoine Quint]

Submitted web-platform-tests pull request: https://github.com/web-platform-tests/wpt/pull/54429

[EWS]

Committed 298975@main (179a9082a09b): <https://commits.webkit.org/298975@main>

Reviewed commits have been landed. Closing PR #49660 and removing active labels.