523551 - nsStyleAnimation needs to handle animating between lengths with & without units

Status: NEW

(Core :: CSS Parsing and Computation, defect)

Description

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

STEPS TO REPRODUCE:
 0. Enable 'svg.smil.enabled' pref
 1. Load testcase in a recent mozilla-central nightly build

EXPECTED BEHAVIOR: The three rects should have identical, smoothly interpolated stroke-width animations.

ACTUAL BEHAVIOR: The first two rects are fine, but the third drops into discrete animation. (interpolation fails)

This happens because the third rect animates from a unitless value to a "px" value.
 - The unitless value translates into a nsStyleCoord computed value with type eStyleUnit_Factor and value equal to the specified value.
 - The px value ends up giving us a nsStyleCoord with type = eStyleUnit_Coord, and value = the specified length in app-units.
 - Interpolation ends up failing because the units conflict in the resulting pair of nsStyleAnimation::Values. (eUnit_Float vs eUnit_Coord)

The patch in bug 523355 handles this same issue for lengths in CSS lists -- that patch just converts all lengths it encounters into float values.  We should probably do that here, too.  However, we probably *only* want to do this for those properties that can have both unit-bearing and unitless computed values.  Maybe we need a new nsStyleAnimType to separate these properties from the rest of the length-valued properties (whose values we don't need to convert into floats)?

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20091019 Minefield/3.7a1pre

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This is a quirk of SVG properties, which support unitless numbers as meaning the same as 'px' (which SVG wanted for all properties, and we implemented only for the SVG-specific ones); we allow the distinction between two types that are the same through all the way to the code that gets the style data, which is probably a bad idea in the first place.

Comment 2

[Daniel Holbert [:dholbert]]

(In reply to comment #1)
> we allow the distinction between two types that are
> the same through all the way to the code that gets the style data, which is
> probably a bad idea in the first place.

If you're suggesting that it'd be better to *only* use nscoord to store these values in the style system, note that this could run us into more bugs like the one described in this thread:
http://groups.google.com/group/mozilla.dev.tech.svg/browse_thread/thread/7dad0d6af3f6b2c9/ae8f6973906a2cae

Basically, the bug there is that very small unitless 'font-size' values get clamped to zero (even in very large <svg> elements, scaled up enough so that small font-sizes *should* display at a reasonably-visible size).

Right now, I think we hit that bug for 'font-size' but not for e.g. 'stroke-width' because the style system stores unitless values in a float for 'stroke-width', but in a nscoord for 'font-size'.