Bug 7430 – Invalid opacity values are treated incorrectly

• Status: RESOLVED
• Resolution: FIXED
• Component: CSS

[Brad Fults]

CSS styles exposed through the DOM should be treated as numbers (floats specifically) when the style takes a unitless float value.

A simple example of this is opacity:

el.style.opacity = 0.3; //works fine
el.style.opacity = 1.3877787807814457e-16; // fails -- Webkit invalidates the style altogether (yielding opacity == 1.0)

This will also fail for values specified in octal or hexadecimal, as they are treated as strings.

This does work as expected in Firefox 1.5 (converting the numbers), however.

[Brad Fults]

Created attachment 6681 [details]
Test case: simple fader.

[Alexey Proskuryakov]

Created attachment 8069 [details]
reduced test case

[Alexey Proskuryakov]

Trying to set the opacity to an invalid value such as 1e-16 has no effect in Firefox, but resets it in Safari. I'm not quite sure about what constitutes an invalid value, but the issue doesn't look like related to strings to me.

[Brad Fults]

The so-called "invalid value" is a valid Number literal in JS. I suppose whether it's an "invalid value" depends entirely on whether the DOM as bound to by JS is supposed to only accept numbers in a specific format (decimal) or if any JS Number should be converted to a value suitable for DOM assignment.

[Alexey Proskuryakov]

(In reply to comment #4)
> The so-called "invalid value" is a valid Number literal in JS.

That's correct, but then it's converted back to a string and passed to CSS parser, which doesn't understand scientific notation.

The problem with handling invalid values has been recently fixed, see bug 7296. The test case now works just like it does in Firefox. We just don't log an error to the console yet, unlike Firefox.