Bug 149911
| Summary: | document.execCommand() should not count as a "user edit" for the purposes of ValidityState.tooLong | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Chris Rebert <webkit> |
| Component: | Forms | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED INVALID | ||
| Severity: | Normal | CC: | ap, cdumez, enrica, rniwa |
| Priority: | P2 | Keywords: | HasReduction |
| Version: | WebKit Nightly Build | ||
| Hardware: | All | ||
| OS: | All | ||
| URL: | http://jsfiddle.net/cvrebert/vdy3emx2/ | ||
Chris Rebert
Steps to reproduce the problem:
1. Open http://jsfiddle.net/cvrebert/vdy3emx2/ in WebKit Nightly
2. Look at the console output.
What is the expected behavior?
The console output should be:
> Before script edit: false
> After script edit: false
Quoting from https://html.spec.whatwg.org/multipage/forms.html#attr-fe-maxlength
> Constraint validation: If an element has a maximum allowed value length, its dirty value flag is true, its value was last changed by a user edit (as opposed to a change made by a script), and the code-unit length of the element's value is greater than the element's maximum allowed value length, then the element is suffering from being too long.
Since the <input>'s value was last changed by script unbiddenly invoking document.execCommand(), which should count as a script edit, not a user edit, the <input>'s validity.tooLong boolean should remain false because the "its value was last changed by a user edit (as opposed to a change made by a script)" condition has not been satisfied.
What went wrong?
The actual console output is:
> Before script edit: false
> After script edit: true
Which indicates that document.execCommand() is being treated as a "user edit", thus causing input.validity.tooLong to become true.
This bug is causing some test failures in
http://w3c-test.org/html/semantics/forms/constraints/form-validation-validity-tooLong.html
(AKA https://github.com/w3c/web-platform-tests/blob/master/html/semantics/forms/constraints/form-validation-validity-tooLong.html )
Analogous Chrome bug: https://code.google.com/p/chromium/issues/detail?id=540978
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Ryosuke Niwa
The test is broken.
execCommand is an unspec'ed feature, and only Blink and WebKit allows deletion inside input and textarea elements.
All other browsers are passing the test case because execCommand doesn't do anything in those browsers.
We need to fix the W3C test instead.
Ryosuke Niwa
See https://github.com/w3c/web-platform-tests/issues/923