The implementation of adjust_horizontal_to_limit() is written with UI in
mind. As such, when there's a selection and we "adjust horizontal", the
selection will be cleared and the cursor will and up at the start/end of
the previous selection. This is what happens when you have a selection
and you press an arrow key on your keyboard, but it isn't the behaviour
we want when programmatically changing the value.
Instead, we need to first clear the selection, and then move the cursor
to the end. (We also need to reset the selection direction when clearing
the selection.)
Per the spec, selectionStart and selectionEnd should return the same
values regardless of the selectionDirection. (That is, selectionStart is
always less than or equal to selectionEnd; the direction then implies
which of selectionStart or selectionEnd is the cursor position.)
There was no explicit WPT test for this, so I added one.
This bug was initially quite hard to wrap my head around, and I think
part of the problem is the code in TextInput. Therefore, in the process
of fixing it I have refactored the implementation of TextInput:
* Rename selection_begin to selection_origin. This value doesn't
necessarily correspond directly to the selectionStart DOM value - in
the case of a backward selection, it corresponds to selectionEnd.
I feel that "origin" doesn't imply a specific ordering as strongly as
"begin" (or "start" for that matter) does.
* In various other cases where "begin" is used as a synonym for "start",
just use "start" for consistency.
* Implement selection_start() and selection_end() methods (and their
_offset() variants) which directly correspond to their DOM
equivalents.
* Rename other related methods to make them less wordy and more
consistent / intention-revealing.
* Add assertions to assert_ok_selection() to ensure that our assumptions
about the ordering of selection_origin and edit_point are met. This
then revealed a bug in adjust_selection_for_horizontal_change() where
the value of selection_direction was not maintained correctly (causing
a unit test failure when the new assertion failed).
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.
Servo currently uses `heapsize`, but Stylo/Gecko use `malloc_size_of`.
`malloc_size_of` is better -- it handles various cases that `heapsize` does not
-- so this patch changes Servo to use `malloc_size_of`.
This patch makes the following changes to the `malloc_size_of` crate.
- Adds `MallocSizeOf` trait implementations for numerous types, some built-in
(e.g. `VecDeque`), some external and Servo-only (e.g. `string_cache`).
- Makes `enclosing_size_of_op` optional, because vanilla jemalloc doesn't
support that operation.
- For `HashSet`/`HashMap`, falls back to a computed estimate when
`enclosing_size_of_op` isn't available.
- Adds an extern "C" `malloc_size_of` function that does the actual heap
measurement; this is based on the same functions from the `heapsize` crate.
This patch makes the following changes elsewhere.
- Converts all the uses of `heapsize` to instead use `malloc_size_of`.
- Disables the "heapsize"/"heap_size" feature for the external crates that
provide it.
- Removes the `HeapSizeOf` implementation from `hashglobe`.
- Adds `ignore` annotations to a few `Rc`/`Arc`, because `malloc_size_of`
doesn't derive those types, unlike `heapsize`.
Fixes warnings from rust-lang/rust#44229 when `--enable-commonmark` is
passed to rustdoc.
This is mostly a global find-and-replace for bare URIs on lines by
themselves in doc comments.
The `cfg` attribute in use resulted in two match arms for two cases on
`macos`. Since both arms had a main functionality in common, I merged
them and conditions the extra `macos` part.
```
warning: unreachable pattern
-->
/Users/behnam/code/servo/servo/components/script/textinput.rs:696:13
|
696 | (None, Key::Home) => {
| ^^^^^^^^^^^^^^^^^
|
= note: #[warn(unreachable_patterns)] on by default
warning: unreachable pattern
-->
/Users/behnam/code/servo/servo/components/script/textinput.rs:700:13
|
700 | (None, Key::End) => {
| ^^^^^^^^^^^^^^^^
|
= note: #[warn(unreachable_patterns)] on by default
```
Correct unicode handling for text input
<!-- Please describe your changes on the following line: -->
Allow proprer handling of unicode sequence in text input.
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#15819
<!-- Either: -->
- [ ] There are tests for these changes OR
- [ ] These changes do not require tests because _____
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/15822)
<!-- Reviewable:end -->
Hitting the tab key in an html text input shouldn't submit the form, and
for any text input, the tab key should have a particular action
associated, not the default action. This cleans up #12701.
The methods which are currently implemented are the ones on String that are currently being used:
string.push_str(...), string.clear() and string.extend(...). We may want to revisit this API.
This should make it somewhat easier to experiment with alternative
representations in the future. To reduce churn, this commit leaves the String
field public, though.
Also, this will allow us to use the default String type to represent the IDL
USVString type, which explicitly forbids unpaired surrogates, ans as such is
a better match to the Rust String type.
