In our current implementation, in order to avoid a step mismatch, the actually step used is the LCM of 'step' and 'step scale factor'. This is kind of confusing when step is non-integer, for example, when step is 0.9 (day), the actually step used is 9 (days) [1]. Note that the step scale factor for type=date is 86400000 (which converts the days to milliseconds). What Chromium does is, for type=date, month and week, they round the step [2], so when step is 0.9 (day), the actually step used is 1 (day), and when step is 1.6, the actually step used is 2. I can't tell what Edge does, cause they seem not to set the validationMessage. The spec just says: "When the element is suffering from a step mismatch, the user agent may round the element's value to the nearest date for which the element would not suffer from a step mismatch." [3] [1] http://hg.mozilla.org/mozilla-central/file/711963e8daa3/dom/html/test/forms/test_step_attribute.html#l204 [2] https://chromium.googlesource.com/chromium/blink/+/master/Source/core/html/forms/StepRange.cpp#126 [3] https://html.spec.whatwg.org/multipage/forms.html#date-state-(type=date)

Comment on attachment 8774622 [details] [diff] [review] patch, v1. Review of attachment 8774622 [details] [diff] [review]: ----------------------------------------------------------------- Just round the value of step attribute for type=date.

Comment on attachment 8774622 [details] [diff] [review] patch, v1. Doesn't this break inputelement.step getter? https://html.spec.whatwg.org/multipage/forms.html#the-step-attribute With step 0.9, blink keeps returning 0.9.

(In reply to Olli Pettay [:smaug] from comment #3) > Comment on attachment 8774622 [details] [diff] [review] > patch, v1. > > Doesn't this break inputelement.step getter? > https://html.spec.whatwg.org/multipage/forms.html#the-step-attribute No, it doesn't. The GetStep() here is used internally for computations, the step attribute getter uses the NS_IMPL_STRING_ATTR macro [1]. I'll add a test to verify this. > > With step 0.9, blink keeps returning 0.9. [1] http://hg.mozilla.org/mozilla-central/file/462dc6b44adb/dom/html/HTMLInputElement.cpp#l1592

Added tests to check step attribute value is unchanged

Comment on attachment 8774991 [details] [diff] [review] patch, v2. I see, thanks.

Update form-validation-reportValidity.html expectation data: tests don't timeout now since we no longer use EuclidLCM functions.

Pushed by ryanvm@gmail.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/91eaa3e92b41 Simplify the computation of step values for input type=date. r=smaug