ISSUE-20455: introduce stronger types for textinput indexing
<!-- Please describe your changes on the following line: -->
Added two new types:
- ByteOffset
- UTF16CodeUnitOffset
I've replaced any instance of `usize` that would be better represented by one or the other of these. I also updated any downstream code, including the unit tests for `textinput.rs`. Along the way, I tried to add or edit comments to better reflect my understanding of this file - happy to revisit if I have misrepresented anything.
I did not end up finding any places where types were very obviously being mixed, as the issue description suggested I should do... LMK if I should re-audit the file for that (might need a bit of guidance)!
---
<!-- 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#20455 (GitHub issue number if applicable)
<!-- Either: -->
- [X] There are tests for these changes OR
- [ ] These changes do not require tests because ___
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- 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/23272)
<!-- Reviewable:end -->
This includes a `size_of` regression for a few DOM types,
due to https://github.com/rust-lang/rust/pull/58623 which replaces the
implementation of `HashMap` in the standard library to Hashbrown.
Although `size_of<HashMap>` grows, it’s not obvious how total memory usage
is going to be impacted: Hashbrown only has one `u8` instead of one `usize`
of overhead per hash table bucket for storing (part of) a hash,
and so might allocate less memory itself.
Hashbrown also typically has better run time performance:
https://github.com/rust-lang/hashbrown#performance
Still, I’ve filed https://github.com/rust-lang/hashbrown/issues/69
about potentially reducing the `size_of<HashMap>` regression.
Use keyboard-types::webdriver::send_keys
This improves the quality of KeyboardEvents sent by WebDriver. Now key, code, location and modifiers are set according to spec. CompositionEvents are discarded as servo does not handle them at all.
CompositionEvent support can be added later.
Is there a good way to automatically test this?
<!-- 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/22173)
<!-- Reviewable:end -->
This improves the quality of KeyboardEvents
sent by WebDriver. Now key, code, location and
modifiers are set according to spec.
CompositionEvents are discarded as servo
does not handle them at all.
Use line comments instead of block comments
as block comments contain trailing whitespace
after formatting with rustfmt.
Skip tests for malloc_size_of and script_plugins
with rustfmt as they have many block comments.
Use keyboard-types crate
Have embedders send DOM keys to servo and use a strongly typed KeyboardEvent
from the W3C UI Events spec. All keyboard handling now uses the new types.
Introduce a ShortcutMatcher to recognize key bindings. Shortcuts are now
recognized in a uniform way.
Updated the winit port.
Updated webdriver integration.
part of #20331
What this PR does:
* allow the use non-ASCII keyboards for text input
* decouple keyboard event "key" from "code" (key meaning vs location)
What this PR does not do:
* completely improve keyboard events send from winit and webdriver
* add support for CompositionEvent or IME
Notes:
* The winit embedder does not send keyup events for printable keys (this is a regression)
* keyboard-types is on crates.io because I believe it to be useful outside of servo. If you prefer I can add a copy in this repo.
<!-- 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/21881)
<!-- Reviewable:end -->
Have embedders send DOM keys to servo and use a strongly typed KeyboardEvent
from the W3C UI Events spec. All keyboard handling now uses the new types.
Introduce a ShortcutMatcher to recognize key bindings. Shortcuts are now
recognized in a uniform way.
Updated the winit port.
Updated webdriver integration.
part of #20331
Previously, the `tests` feature flag of the `embedder_traits` crate
caused it and every crate recursively depending on it to be built twice.
This feature flag was used to provide a specific set of "resources"
when running tests. Instead, this commits overrides the `main()` function
of the test harness to change resources at runtime before running any test.
This is done by adding a dependency that has `name = "test"` in its
`[lib]` section of `Cargo.toml`. This overrides the crate found by
`extern crate test;` in code generated by `rustc --test`.
Replace Servo DL items with WR ones
The Servo internal display list items are already pretty much
equivalent to the WebRender ones. Except that Servo items contain
base information and associated glyphs and gradient stops which are
stored implicitly in WebRender. Remove the display items for
rectangles, text, images, border, gradients and box shadow and
replace them with their WebRender counter parts.
Some more internal items like line, text shadow and iframe can definitively be replaced with WebRender equivalents but I think the PR is already quite huge. If WebRender would expose a quite minimal API which allowed servo to directly push items onto the display list most of webrender_helpers boilerplate code could go away. As WebRender performs normalization of gradients this would need to be called by servo explicitly in this case.
It should be noted that gradient borders don't actually work neither with the old version nor with this PR as the measurements are all set to zero.
Part of #19676
<!-- 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/21348)
<!-- Reviewable:end -->
