Bug 166962 - Large negative animation-delays may not work depending on machine uptime
Summary: Large negative animation-delays may not work depending on machine uptime
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Animations (show other bugs)
Version: Safari 10
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Dean Jackson
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2017-01-11 20:30 PST by David Bruchmann
Modified: 2017-04-14 09:55 PDT (History)
8 users (show)

See Also:


Attachments
Testcase (506 bytes, text/html)
2017-01-18 22:52 PST, Simon Fraser (smfr)
no flags Details
SVG testcase (1.67 KB, text/html)
2017-01-18 22:56 PST, Simon Fraser (smfr)
no flags Details
Patch (18.78 KB, patch)
2017-04-13 18:49 PDT, Dean Jackson
thorton: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description David Bruchmann 2017-01-11 20:30:54 PST
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>
Comment 1 Alexey Proskuryakov 2017-01-14 00:23:58 PST
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.
Comment 2 David Bruchmann 2017-01-14 10:40:45 PST
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.
Comment 3 David Bruchmann 2017-01-14 11:39:38 PST
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.
Comment 4 Simon Fraser (smfr) 2017-01-14 13:00:27 PST
The CSS spec allows user agents to clamp large values, as long as the clamped values round-trip.
Comment 5 David Bruchmann 2017-01-14 18:01:11 PST
@Simon Fraser, can you give an example?
And does it help to solve the bug?
Comment 6 David Bruchmann 2017-01-18 22:25:43 PST
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.
Comment 7 Simon Fraser (smfr) 2017-01-18 22:51:53 PST
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.
Comment 8 Simon Fraser (smfr) 2017-01-18 22:52:09 PST
Created attachment 299233 [details]
Testcase
Comment 9 Radar WebKit Bug Importer 2017-01-18 22:53:46 PST
<rdar://problem/30091526>
Comment 10 Simon Fraser (smfr) 2017-01-18 22:56:15 PST
Created attachment 299234 [details]
SVG testcase
Comment 11 David Bruchmann 2017-01-18 23:05:49 PST
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.
Comment 12 Dean Jackson 2017-04-13 18:49:30 PDT
Created attachment 307070 [details]
Patch
Comment 13 Dean Jackson 2017-04-13 18:57:19 PDT
Committed r215352: <http://trac.webkit.org/changeset/215352>
Comment 14 Simon Fraser (smfr) 2017-04-14 02:36:17 PDT
Nice.
Comment 15 David Bruchmann 2017-04-14 09:55:15 PDT
Can't test it in lack of safari / apple but assume it's fine.
Thanks!