Commit graph

3 commits

Author SHA1 Message Date
Jon Leighton
71a013dd50 Handle cases where selection API doesn't apply
The selection API only applies to certain <input> types:

https://html.spec.whatwg.org/multipage/#do-not-apply

This commit ensures that we handle that correctly.

Some notes:

1. TextControl::set_dom_selection_direction now calls
   set_selection_range(), which means that setting selectionDirection will
   now fire a selection event, as it should per the spec.

2. There is a test for the firing of the select event in
   tests/wpt/web-platform-tests/html/semantics/forms/textfieldselection/select-event.html,
   however the test did not run due to this syntax error:

   (pid:26017) "ERROR:script::dom::bindings::error: Error at http://web-platform.test:8000/html/semantics/forms/textfieldselection/select-event.html:50:11 missing = in const declaration"

   This happens due to the us of the "for (const foo of ...)" construct.
   Per https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for...of
   this should actually work, so it's somewhat unsatisfying to have to
   change the test.

4. If an <input>'s type is unset, it defaults to a text, and the
   selection API applies. Also, if an <input>'s type is set to an
   invalid value, it defaults to a text too. I've expanded the tests
   to account for this second case.
2017-12-08 21:07:05 +01:00
Jon Leighton
9b06cb3369 Handle setting selectionStart to be > selectionEnd 2017-11-25 16:36:01 +01:00
Jon Leighton
6beda3c761 Extract common text control selection code
The API for text control selection is the same for both <input> and
<textarea>:

https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#textFieldSelection

Before this change, they had similar but not identical implementations
with duplicate code. Now there is a common TextControl trait which
contains the implementation used by both. As a result, some previously
failing tests now pass.
2017-11-18 22:33:05 +01:00