<rdar://problem/88488519>

I believe the failure has something to do with cubic bezier timing.

Our failures are: FAIL CSS Transitions: property <font-variation-settings> from ['aaaa' 30, 'bbbb' 20] to ['aaaa' 20, 'bbbb' 30] at (3.40282e+38) should be ['aaaa' -3.40282e+38, 'bbbb' 3.40282e+38] assert_array_equals: expected property 0 to be "\"aaaa\" -3.40282e+38" but got "\"aaaa\" -Infinity" (expected array ["\"aaaa\" -3.40282e+38", "\"bbbb\" 3.40282e+38"] got ["\"aaaa\" -Infinity", "\"bbbb\" Infinity"]) FAIL CSS Transitions with transition: all: property <font-variation-settings> from ['aaaa' 30, 'bbbb' 20] to ['aaaa' 20, 'bbbb' 30] at (3.40282e+38) should be ['aaaa' -3.40282e+38, 'bbbb' 3.40282e+38] assert_array_equals: expected property 0 to be "\"aaaa\" -3.40282e+38" but got "\"aaaa\" -Infinity" (expected array ["\"aaaa\" -3.40282e+38", "\"bbbb\" 3.40282e+38"] got ["\"aaaa\" -Infinity", "\"bbbb\" Infinity"]) FAIL CSS Animations: property <font-variation-settings> from ['aaaa' 30, 'bbbb' 20] to ['aaaa' 20, 'bbbb' 30] at (3.40282e+38) should be ['aaaa' -3.40282e+38, 'bbbb' 3.40282e+38] assert_array_equals: expected property 0 to be "\"aaaa\" -3.40282e+38" but got "\"aaaa\" -Infinity" (expected array ["\"aaaa\" -3.40282e+38", "\"bbbb\" 3.40282e+38"] got ["\"aaaa\" -Infinity", "\"bbbb\" Infinity"]) FAIL Web Animations: property <font-variation-settings> from ['aaaa' 30, 'bbbb' 20] to ['aaaa' 20, 'bbbb' 30] at (3.40282e+38) should be ['aaaa' -3.40282e+38, 'bbbb' 3.40282e+38] assert_array_equals: expected property 0 to be "\"aaaa\" -3.40282e+38" but got "\"aaaa\" -Infinity" (expected array ["\"aaaa\" -3.40282e+38", "\"bbbb\" 3.40282e+38"] got ["\"aaaa\" -Infinity", "\"bbbb\" Infinity"]) It looks like a serialization problem to me where we use "Infinity" here.

The large number ends up getting rounded to Infinity at some point during the animation process. I think it has to do with conversion between double and float, but I can’t pinpoint exactly where it happens.

By the time the serialization happens, the value is a floating point infinity, so it does not seem to be a bug in the serialization code itself, but rather in the animation code.

The issue is that we're animating font-variation-settings values which are floats and using a very large progress value for blending that itself is represented as a double. The blending happens in this method: static inline float blendFunc(float from, float to, const CSSPropertyBlendingContext& context) { if (context.compositeOperation == CompositeOperation::Replace) return narrowPrecisionToFloat(from + (to - from) * context.progress); return narrowPrecisionToFloat(from + from + (to - from) * context.progress); } If we returned a double here, we would retain the precision, but narrowPrecisionToFloat() leads to the Infinity value.

(In reply to Antoine Quint from comment #6) > The issue is that we're animating font-variation-settings values which are > floats and using a very large progress value for blending that itself is > represented as a double. The blending happens in this method: > > static inline float blendFunc(float from, float to, const > CSSPropertyBlendingContext& context) > { > if (context.compositeOperation == CompositeOperation::Replace) > return narrowPrecisionToFloat(from + (to - from) * context.progress); > return narrowPrecisionToFloat(from + from + (to - from) * > context.progress); > } > > If we returned a double here, we would retain the precision, but > narrowPrecisionToFloat() leads to the Infinity value. In the past, I tried to clamp narrowPrecisionToFloat in bug 245356 and it changed this test from infinity to value. PR - https://github.com/WebKit/WebKit/pull/4580

Also Blink templatize the blend function in following crbug.com/276109 by fixing underflow issues in current code.