The TextInput::assert_ok_selection() method is meant to ensure that we
are not getting into a state where a selection refers to a location in
the control's contents which doesn't exist.
However, before this change we could have a situation where the
internals of the TextInput are changed by another part of the code,
without using its public API. This could lead to us having an invalid
selection.
I did manage to trigger such a situation (see the test added in this
commit) although it is quite contrived. There may be others that I
didn't think of, and it's also possible that future changes could
introduce new cases. (Including ones which trigger panics, if indexing
is used on the assumption that the selection indices are always valid.)
The current HTML specification doesn't explicitly say that
selectionStart/End must remain within the length of the content, but
that does seems to be the consensus reached in a discussion of this:
https://github.com/whatwg/html/issues/2424
The test case I've added here is currently undefined in the spec which
is why I've added it in tests/wpt/mozilla.
Source-Repo: https://github.com/servo/servo
Source-Revision: f6463c89d50b0ebc377bfe10bd0ffe0c59dd84ca
The intention here is to make the flow more explicit. I.e. rather than
calling `self.dom_select()` and relying on the programmer to
know/realise that this method is provided by a trait, we call
`self.selection().dom_select()` and the programmer can inspect the
definition of `self.selection()` to follow the code.
This came out of a discussion with KiChjang here:
https://github.com/servo/servo/pull/19544#discussion_r156167044
Note that I tried to make "selection" be a member field of
HTML{Input,TextArea}Element but it opened up a whole can of worms with
lifetimes, so it seemed simpler to not do that since it is not
essential for this code to work.
r? @jdm and @KiChjang
Source-Repo: https://github.com/servo/servo
Source-Revision: ff54a58694af43fc549baa6c64bf6ebc5c37385f
This is my next batch of changes for issue #19171. All the tests in tests/wpt/metadata/html/semantics/forms/textfieldselection/ are now passing (and also some tests outside of there).
I've made detailed notes about the changes in each commit message.
r? @KiChjang
Source-Repo: https://github.com/servo/servo
Source-Revision: c2dfece49f1d59f51a3207cd3d88c282ee1adf70
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.
3. I removed tests/wpt/web-platform-tests/html/semantics/forms/textfieldselection/selection-not-application-textarea.html
because it doesn't seem to add any extra value - the selection API
always applies to textarea elements, and the API is tested elsewhere.
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. This second case doesn't
currently work, and I'll need to do more restructuring of the code in
a future commit. See discussion with nox in IRC:
https://mozilla.logbot.info/servo/20171201#c13946454-c13946594
Source-Repo: https://github.com/servo/servo
Source-Revision: db41cc00be93523114092125859534b107ec772a
