New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 633074 link

Starred by 3 users

Issue metadata

Status: Fixed
Merged: issue 633149
Owner:
Closed: Nov 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug

Blocked on:
issue 655412



Sign in to add a comment

Input[range] doesn't set correct value after updating the step attribute

Reported by mjsta...@gmail.com, Aug 1 2016

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.82 Safari/537.36

Example URL:
http://plnkr.co/edit/GImfZsC0sNNtoXw12M5h?p=preview

Steps to reproduce the problem:
The test case in the plnkr should speak for itself. Manual steps follow:
1. Create a range input with a step of 10
2. Change the step to 15 // value changes to 45
3. Change the step to 20

What is the expected behavior?
The range input should now have a value of 40

What went wrong?
The range input should now has a value of 60

Does it occur on multiple sites: Yes

Is it a problem with a plugin? No 

Did this work before? N/A 

Does this work in other browsers? Yes 

Chrome version: 52.0.2743.82  Channel: stable
OS Version: 10.0
Flash Version: Shockwave Flash 22.0 r0

This works as expected in FF 47.0.1 and Edge 25.10586.
 

Comment 1 by mjsta...@gmail.com, Aug 1 2016

I've also tested in Version 54.0.2815.0 canary (64-bit), and it's also broken.

Comment 2 by kojii@chromium.org, Aug 1 2016

Components: -Blink Blink>Forms>Range
Labels: -OS-Windows OS-All
Blink/WebKit fails while Gecko passes, not sure about spec.

Comment 3 by kojii@chromium.org, Aug 1 2016

 Issue 633075  has been merged into this issue.
Cc: ashej...@chromium.org
Mergedinto: 633149
Status: Duplicate (was: Unconfirmed)
Issue dupe of 633149 hence merging the same as info is provided in the bug.

Comment 5 by mjsta...@gmail.com, Aug 2 2016

hm I don't understand why this was merged into https://bugs.chromium.org/p/chromium/issues/detail?id=633149, which is a completely different bug (it is about date input element). This is about the range input element. Am I missing something?
Status: Unconfirmed (was: Duplicate)
Hey, apologies for the confusion, un-merging as per comment #5.

Thank you!

Comment 7 by tkent@chromium.org, Aug 2 2016

Labels: -Pri-2 Hotlist-Interop Pri-3
Status: Available (was: Unconfirmed)
I think the specification doesn't define how to change the value on setting |step| attribute.  So, this behavior isn't wrong.  However, this is an interoperability issue.

Comment 8 by mjsta...@gmail.com, Aug 3 2016

The spec actually defines what should happen when the input suffers from step mismatch: 

-----------
When the element is suffering from a step mismatch, the user agent must round the element's value to the nearest number for which the element would not suffer from a step mismatch, and which is greater than or equal to the minimum, and, if the maximum is not less than the minimum, which is less than or equal to the maximum, if there is a number that matches these constraints. If two numbers match these constraints, then user agents must use the one nearest to positive infinity.
------------

https://www.w3.org/TR/html5/forms.html#range-state-(type=range)

Chrome also implements this partly, as you can see in the reproduction: the first time the step is changed (to 15), the value changes correctly, but not for the next time it is changed (to 20).

Please also note that issue https://bugs.chromium.org/p/chromium/issues/detail?id=633075 which was closed as a duplicate should be considered as an additional test case.

Comment 9 by tkent@chromium.org, Aug 3 2016

#8, you're right!  Thanks.

Comment 10 by tkent@chromium.org, Sep 23 2016

Owner: tkent@chromium.org
Status: Started (was: Available)

Comment 12 by tkent@chromium.org, Sep 25 2016

Labels: M-55
Status: Fixed (was: Started)

Comment 13 by tkent@chromium.org, Sep 25 2016

Labels: -M-55
Status: Assigned (was: Fixed)
oops, #420798 didn't fix this perfectly. Reopen.

Comment 14 by tkent@chromium.org, Sep 26 2016

There were two bugs.

A) Updating 'step' attribute didn't update the *dirty* value.
B) Updating 'step' attribute doesn't refer to the last value, but the default value if the value is not dirty.

#420798 fixed only A.


Project Member

Comment 15 by bugdroid1@chromium.org, Sep 27 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/930e066130dc8621d4b25c8bfe14d8fff315404e

commit 930e066130dc8621d4b25c8bfe14d8fff315404e
Author: tkent <tkent@chromium.org>
Date: Tue Sep 27 04:17:47 2016

Introduce HTMLInputElement::m_hasDirtyValue.

Add a bool flag to represent the dirty flag [1]. We replace
!m_valueIfDirty.isNull() for dirty flag checking with the new flag.

This CL has no behavior changes.  This CL is a preparation to make
m_valueIfDirty a permanent storage of |value| IDL attribute.

[1] https://html.spec.whatwg.org/multipage/forms.html#concept-input-value-dirty-flag
[2] https://html.spec.whatwg.org/multipage/forms.html#dom-input-value

BUG= 633074 

Review-Url: https://codereview.chromium.org/2368193002
Cr-Commit-Position: refs/heads/master@{#421100}

[modify] https://crrev.com/930e066130dc8621d4b25c8bfe14d8fff315404e/third_party/WebKit/Source/core/html/HTMLInputElement.cpp
[modify] https://crrev.com/930e066130dc8621d4b25c8bfe14d8fff315404e/third_party/WebKit/Source/core/html/HTMLInputElement.h

Comment 16 by tkent@chromium.org, Oct 13 2016

Blockedon: 655412

Comment 17 by tkent@chromium.org, Oct 31 2016

Status: Started (was: Assigned)
Project Member

Comment 18 by bugdroid1@chromium.org, Oct 31 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9763e857c8822745fb03e460e1bafdb638b95d71

commit 9763e857c8822745fb03e460e1bafdb638b95d71
Author: tkent <tkent@chromium.org>
Date: Mon Oct 31 07:18:03 2016

INPUT element: Updating 'step' attribute should adjust the last value.

Bug:
If
 - 'step' attribute is updated,
 - we adjust the value, and
 - the value is not dirty,
we adjusted the default value instead of the last value.

Implementation:
We didn't store the last value if the value is not dirty, and compute the value
on the fly.
With this CL, we always store the current value to
HTMLInputElement::m_valueIfDirty though we stored only a dirty value.
 * When |value| attribute is updated, we update m_valueIfDirty as well.
 * Remove special handling of null m_valueIfDirty
  Because setValue(null0string) doesn't clear hasDirtyValue() flag, this CL
  introduces setNonDirtyValue() like HTMLTextAreaElement::setNonDirtyValue().
 * Make HTMLInputElement::value() clearer.

BUG= 633074 

Review-Url: https://codereview.chromium.org/2463693002
Cr-Commit-Position: refs/heads/master@{#428663}

[modify] https://crrev.com/9763e857c8822745fb03e460e1bafdb638b95d71/third_party/WebKit/LayoutTests/fast/forms/range/range-set-attribute-expected.txt
[modify] https://crrev.com/9763e857c8822745fb03e460e1bafdb638b95d71/third_party/WebKit/LayoutTests/fast/forms/range/range-set-attribute.html
[modify] https://crrev.com/9763e857c8822745fb03e460e1bafdb638b95d71/third_party/WebKit/Source/core/html/HTMLInputElement.cpp
[modify] https://crrev.com/9763e857c8822745fb03e460e1bafdb638b95d71/third_party/WebKit/Source/core/html/HTMLInputElement.h
[modify] https://crrev.com/9763e857c8822745fb03e460e1bafdb638b95d71/third_party/WebKit/Source/core/html/forms/InputType.h
[modify] https://crrev.com/9763e857c8822745fb03e460e1bafdb638b95d71/third_party/WebKit/Source/core/html/forms/RangeInputType.cpp
[modify] https://crrev.com/9763e857c8822745fb03e460e1bafdb638b95d71/third_party/WebKit/Source/core/html/forms/TextFieldInputType.cpp

Labels: M-56
Status: Fixed (was: Started)

Sign in to add a comment