[wpt-sync] Sync PR 20711 - Fixes stepUp() and stepDown() are inconsistent with up/down arrow.
Categories
(Core :: DOM: Core & HTML, task, P4)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox73 | --- | fixed |
People
(Reporter: wpt-sync, Unassigned)
References
()
Details
(Whiteboard: [wptsync downstream])
Sync web-platform-tests PR 20711 into mozilla-central (this bug is closed when the sync is complete).
PR: https://github.com/web-platform-tests/wpt/pull/20711
Details from upstream follow.
yu han <yuzhehan@chromium.org> wrote:
Fixes stepUp() and stepDown() are inconsistent with up/down arrow.
Previous to this CL, for input type number, calling stepUp() when
its value is greater than max or call stepDown() when its value is
less than min resets its value to max-min boundary. However, if
up/down arrow is used, the value doesn't change.https://html.spec.whatwg.org/multipage/input.html#dom-input-stepup.
The spec, in section 10 with an example, states that the value should
NOT change. Firefox's behavior matches this spec. Safari also follows
this behavior, but it does so by throwing "InvalidStateError".I found that the difference in behavior is caused by two different
call path. Up/Down arrow handler takes care of this case.
Call Path:
KeyUp:
EventDispatcher::Dispatch()
->HTMLInputElement::DefaultEventHandler()
->NumberInputType::HandleKeydownEvent()
->TestFieldInputType::HandleKeydowEventForSpinButton()
->InputType::StepUpFromLayoutObject() // current value range check.StepUp():
V8HTMLInputElement::StepUpMethodCallback()
->HTMLInputElement::stepUp()
->InputType::StepUp()
->InputType::ApplyStep()The fix is to do a check in the StepUp() when input number type's
value and do nothing if the value overflows the corresponding max/min
barrier.I had a general fix in patchset 1, which I reverted. In that patchset,
I do this check inside the InputType::ApplyStep(). However, it had an
unintended regression on time input invalid value test case,
time-stepup-stepdown.html::
shouldBeEqualToString('stepDown("", null, null)', '00:00');
With my previous fix, the value would still be "". Firefox and Safari
both reset the value to be "00:00". I think it's better to preserve the
current behavior and be interoperable. Thus, in the latest patchset, I
made the fix to be specific to input type number.Bug:1019184
Change-Id: Ie6a6aef18b1d0c507b0208a7b5a89ab411bd4028Reviewed-on: https://chromium-review.googlesource.com/1959631
WPT-Export-Revision: ff7af3afd5bfa3a63fd8a40a86a900d50402f44c
|
Assignee | |
Updated•6 years ago
|
|
|
Assignee | |
Comment 1•6 years ago
|
||
|
|
Assignee | |
Comment 2•6 years ago
|
||
CI Results
Ran 13 Firefox configurations based on mozilla-central, and Firefox, Chrome, and Safari on GitHub CI
Total 2 tests and 7 subtests
Status Summary
Firefox
OK : 2
PASS: 14
Chrome
OK : 2
PASS: 2
FAIL: 12
Safari
OK : 2
PASS: 2
FAIL: 12
Links
|
|
Assignee | |
Comment 3•6 years ago
|
||
CI Results
Ran 13 Firefox configurations based on mozilla-central, and Firefox, Chrome, and Safari on GitHub CI
Total 2 tests and 7 subtests
Status Summary
Firefox
OK : 2
PASS: 14
Chrome
OK : 2
PASS: 2
FAIL: 12
Safari
OK : 2
PASS: 2
FAIL: 12
Links
|
|
Assignee | |
Comment 4•6 years ago
|
||
CI Results
Ran 13 Firefox configurations based on mozilla-central, and Firefox, Chrome, and Safari on GitHub CI
Total 2 tests and 7 subtests
Status Summary
Firefox
OK : 2
PASS: 14
Chrome
OK : 2
PASS: 2
FAIL: 12
Safari
OK : 2
PASS: 2
FAIL: 12
Links
|
|
Assignee | |
Comment 6•6 years ago
|
||
CI Results
Ran 13 Firefox configurations based on mozilla-central, and Firefox, Chrome, and Safari on GitHub CI
Total 2 tests and 7 subtests
Status Summary
Firefox
OK : 2
PASS: 14
Chrome
OK : 2
PASS: 2
FAIL: 12
Safari
OK : 2
PASS: 2
FAIL: 12
Links
|
|
Assignee | |
Comment 7•6 years ago
|
||
|
||
Comment 8•6 years ago
|
||
| bugherder | ||
Description
•