Bug 166962 – Large negative animation-delays may not work depending on machine uptime

• Component: Animations
• Status: RESOLVED FIXED

[David Bruchmann]

if some CSS like this is used:

.circle-hours-r3730 { 
	stroke:rgba(0,0,180,0.6);
	animation: keyframes-hours-r3730 43200s infinite;  /* steps(12)*/
	animation-timing-function: linear;
	animation-delay:-21600s;
}

the animation is only working if the seconds for ANIMATION-DELAY cover round about half a day or less.
The detailed amount of accepted seconds seems not clear for me and changing randomly.
So in general the feature animation-delay is working but useless for larger amount of seconds.
As I don't have safari by my own I rely on customer reports. Before declining (hopefully not) please check all possible versions and frameworks.
The randomly changing accepted amount of seconds I discovered with Midori-browser on ubuntu.

An example SVG is this:

<svg width="200" height="200" class="main-container" version="1.1" xmlns="http://www.w3.org/2000/svg">
	<style type="text/css">
		svg.main-container{
			background:transparent;
		}
	</style>
	<svg class="circle-watch-content" viewBox="0 0 10000 10000" preserveAspectRatio="none">
		<style type="text/css">
			.circle-watch-content .donuts {
				-webkit-transform-origin:5000px 5000px;
				-moz-transform-origin:5000px 5000px;
				transform-origin:5000px 5000px;
				
				-webkit-transform: rotate(-90deg);
				-moz-transform: rotate(-90deg);
				transform: rotate(-90deg);
			}
			.circle-watch-content .donuts .donut circle {
				stroke-width:350;
				stroke-dashoffset:0;
				fill:transparent;
			}
			.circle-background { stroke:rgba(256,256,256,0.7); fill:transparent;}
		</style>
		<g class="donuts">
			<svg class="donut donut-r3730">
				<style type="text/css">
					@keyframes keyframes-hours-r3730 {
						  0%      { stroke-dasharray:0 23437; }
						100%      { stroke-dasharray:23436.28 23437; }
					}
					.circle-hours-r3730 { 
						stroke:rgba(0,0,180,0.6);
						animation: keyframes-hours-r3730 43200s infinite;  /* steps(12)*/
						animation-timing-function: linear;
						animation-delay:-21600s;
					}
				</style>
				<circle cx="5000" cy="5000" r="3730" class="circle-background circle-background-r3730"></circle>
				<circle cx="5000" cy="5000" r="3730" class="circle-hours circle-hours-r3730" id="circle-hours-r3730"></circle>
			</svg>
		</g>
	</svg>
</svg>

[Alexey Proskuryakov]

Please clarify why it is desirable to have such long time periods. It is normal that browsers have implementation defined limits, and to consider raising those, a compelling use case would be helpful.

[David Bruchmann]

A simple example and also my purpose was to create an animated watch with 12h and 24h animations. Even if the animation is running is only for a few minutes on client-side I need the long animation-delay to adjust the style applying to the current time.
In chrome and firefox my example above is running, so the bug in safari / webkit is regrettable a reason that the animation is not fully browser-compatible.

[David Bruchmann]

If there exist any limits in firefox and chrome it might be desire-able that any limits in webkit / safari are adjusted to those.
Having own definitions about limits will always raise bug-reports if the limits are more limiting than in other browsers.
In my opinion limits should be given by CSS, JavaScript or the programming-language of Webkit, but not be defined additional.

This is related to all limits that might exist and not only to that of animation-delay.
Nevertheless, I primary am concerned about animaton-delay now and any other limits had to be discussed in other bugs or more general perhaps.

Concerning animaton-delay it's thinkable that it could be used for animations of calendars too, so weeks, month or years (in seconds) could be shown too without limits that are too strict for it.

[Simon Fraser (smfr)]

The CSS spec allows user agents to clamp large values, as long as the clamped values round-trip.

[David Bruchmann]

@Simon Fraser, can you give an example?
And does it help to solve the bug?

[David Bruchmann]

You can see the an example svg here:
https://webdevelopment.barlians.com/news/details/article/clock-just-by-svg-and-css.html

Safari displays the outer circle not and that's related to the problem I mentioned here. The example above is reduced to the outer circle of the online-example.

@Simon Fraser the problems are this:
1) "clamp large values" is not in conformance with other browsers and Safari concerning this and other features is for me as webdeveloper a neck-breaker.
2) Why values are clamped without any reason or why the limits are so low. The unix timestamp works with values since 1970 and I suppose that's not an issue in general.
3) Ranges of values should be defined by applications or real definitions and standards, I don't see any reason that Safari is doing it's own miracles.
4) Round-Tripping concerning hours in a day is not given and if you exceed your own definition the duration of round-tripping is not defined. You can use it for seconds but also for centuries or millennia. Safari is not even covering seconds of a half day and that's my issue here.

[Simon Fraser (smfr)]

The actual bug happens when animation-delay is a large enough negative number that monotonicallyIncreasingTime() + delay becomes negative. So the longer your machine has been running, the greater the negative values that work. This isn't about clamping, it's about WebKit assuming that m_startTime += m_animation->delay() is always positive (where m_startTime is set from monotonicallyIncreasingTime()).

Simpler reduction attached.

[Simon Fraser (smfr)]

Created attachment 299233 [details]
Testcase

[Radar WebKit Bug Importer]

<rdar://problem/30091526>

[Simon Fraser (smfr)]

Created attachment 299234 [details]
SVG testcase

[David Bruchmann]

Ok, thanks for the clarification and adding my example too.

Your example is working fine, but I use chrome on windows and not safari.
Would be nice if the monotonicallyIncreasingTime-function could be changed or removed.
About the negative/positive values I don't know the problem in Safari but in my animation I need working with negative values and in important other browsers that's not an issue.

[Dean Jackson]

Created attachment 307070 [details]
Patch

[Dean Jackson]

Committed r215352: <http://trac.webkit.org/changeset/215352>

[Simon Fraser (smfr)]

Nice.

[David Bruchmann]

Can't test it in lack of safari / apple but assume it's fine.
Thanks!