mirror of
https://github.com/servo/servo.git
synced 2025-10-04 02:29:12 +01:00
ce7bae8834
Spec: https://html.spec.whatwg.org/multipage/#dom-textarea/input-setrangetext In order to do this, we need to define the SelectionMode enum in WebIDL: https://html.spec.whatwg.org/multipage/#selectionmode Since the enum is used by HTMLTextAreaElement and HTMLInputElement, it doesn't seem to make sense to define it in the WebIDL file for one or other of those. However, we also can't create a stand-alone SelectionMode.webidl file, because the current binding-generation code won't generate a "pub mod SelectionMode;" line in mod.rs unless SelectionMode.webidl contains either an interface or a namespace. (This logic happens in components/script/dom/bindings/codegen/Configuration.py:35, in the Configuration.__init__ method.) I thought about changing the binding-generation code, but that seems difficult. So I settled for placing the enum inside HTMLFormElement.webidl, as that seems like a "neutral" location. We could equally settle for putting it under HTMLTextAreaElement or HTMLInputElement, it probably doesn't really matter. The setRangeText algorithm set the "dirty value flag" on the input/textarea. I made some clean-ups related to this: 1. HTMLTextAreaElement called its dirty value flag "value_changed"; I changed this to "value_dirty" to be consistent with the spec. 2. HTMLInputElement had a "value_changed" field and also a "value_dirty" field, which were each used in slightly different places (and sometimes in both places). I consolidated these into a single "value_dirty" field, which was necessary in order to make some of the tests pass. TextControl::set_dom_range_text replaces part of the existing textinput content with the replacement string (steps 9-10 of the algorithm). My implementation changes the textinput's selection and then replaces the selection. A downside of this approach is that we lose the original selection state from before the call to setRangeText. Therefore, we have to save the state into the original_selection_state variable so that we can later pass it into TextControl::set_selection_range. This allows TextControl::set_selection_range to correctly decide whether or not to fire the select event. An alternative approach would be to implement a method on TextInput which allows a subtring of the content to be mutated, without touching the current selection state. However, any such method would potentially put the TextInput into an inconsistent state where the edit_point and/or selection_origin is a TextPoint which doesn't exist in the content. It would be up to the caller to subsequently make sure that the TextInput gets put back into a valid state (which would actually happen, when TextControl::set_selection_range is called). I think TextInput's public API should not make it possible to put it into an invalid state, as that would be a potential source of bugs. That's why I didn't take this approach. (TextInput's public API does currently make it possible to create an invalid state, but I'd like to submit a follow-up patch to lock this down.) |
||
|---|---|---|
| .. | ||
| 2dcontext | ||
| cors | ||
| css | ||
| custom-elements | ||
| dom | ||
| domparsing | ||
| encoding | ||
| eventsource | ||
| fetch | ||
| FileAPI | ||
| fullscreen | ||
| hr-time | ||
| html | ||
| js/builtins | ||
| navigation-timing | ||
| performance-timeline | ||
| quirks | ||
| referrer-policy | ||
| subresource-integrity | ||
| touch-events | ||
| uievents | ||
| url | ||
| WebCryptoAPI | ||
| WebIDL | ||
| websockets | ||
| webstorage | ||
| workers | ||
| xhr | ||
| MANIFEST.json | ||
| mozilla-sync | ||