Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Fix selection{Start,End} when selectionDirection is "backward"
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).
- Loading branch information