Bug 106456 – <input type='date'> rounds the step attribute for stepUp() and stepDown()

• Status: RESOLVED
• Resolution: CONFIGURATION CHANGED
• Component: Forms

[Mounir Lamouri]

Created attachment 181923 [details]
test case

<input type='date'> rounds @step for stepUp() and stepDown() and validity. It seems that in-page UI simply ignores the value.

STEPS TO REPRODUCE:
- create a <input type='date' value='2013-01-01' step='1.5'>
- call stepUp()

ACTUAL RESULT:
- new value is 2013-01-03 (1.5 rounds to 2.0)

EXPECTED RESULT:
- new value is 2013-01-04

See the test case.

[Alexander Shalamov]

From the spec, default step value is 1 day. When it is set to 1.5 days, step is rounded to 2, therefore next value is + 2 days.

"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."

http://dev.w3.org/html5/spec-preview/states-of-the-type-attribute.html#date-state-(type=date)

Looks like invalid bug.

[Mounir Lamouri]

(In reply to comment #1)
> From the spec, default step value is 1 day. *When it is set to 1.5 days, step is rounded to 2, therefore next value is + 2 days.*

Rounding 1.5 to 2 isn't per spec.

> "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."

Indeed and this is the behaviour of stepUp() per spec too: change the value to the next valid value. However, there is a significant difference between going to the next valid value and rounding the step as my test case shows.

[Kent Tamura]

The stepUp/stepDown algorithm in the specification was updated some months ago. WebKit implementation doesn't follow the update yet.

[Ahmad Saleem]

WebKit ToT (280192@main) - this is fixed (post 280189@main + 280127@main):

*** WebKit ToT ***

With step=2.1, next value is: : 2013-01-03 (expected value: 2013-01-22)
With step=2.9, next value is: : 2013-01-03 (expected value: 2013-01-30)

*** Firefox Nightly 129 (20240619213942) ***

With step=2.1, next value is: : 2013-01-03 (expected value: 2013-01-22)
With step=2.9, next value is: : 2013-01-03 (expected value: 2013-01-30)

*** Chrome Canary 128 (128.0.6544.0) ***

With step=2.1, next value is: : 2013-01-03 (expected value: 2013-01-22)
With step=2.9, next value is: : 2013-01-03 (expected value: 2013-01-30)

___

Marking this as 'RESOLVED CONFIGURATION CHANGED', since it is combination of more than bug leading to this bug getting fixed.