mirror of
https://github.com/servo/servo.git
synced 2025-06-16 12:24:29 +00:00
02883a6f54
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). |
||
|---|---|---|
| .. | ||
| Cargo.toml | ||
| headers.rs | ||
| htmlareaelement.rs | ||
| htmlimageelement.rs | ||
| lib.rs | ||
| origin.rs | ||
| size_of.rs | ||
| textinput.rs | ||