aboutsummaryrefslogtreecommitdiffstats
path: root/components/script/dom/htmltextareaelement.rs
Commit message (Collapse)AuthorAgeFilesLines
* Further changes required by ServoOriol Brufau2023-10-021-2/+2
|
* Strict import formatting (grouping and granularity) (#30325)Samson2023-09-111-13/+14
| | | | | * strict imports formatting * Reformat all imports
* remove `extern crate` (#30311)Samson2023-09-081-1/+1
| | | | | | | | | | | * remove extern crate * Update components/script_plugins/lib.rs Co-authored-by: Martin Robinson <mrobinson@igalia.com> --------- Co-authored-by: Martin Robinson <mrobinson@igalia.com>
* No tracing of nop traceable fields (#29926)Samson2023-08-041-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Add `no_trace` option to JSTraceable derive * NoTrace wrapper * Port some types to no_trace schematics * Fixing my unsafe mistakes (not tracing traceables) * Add docs & safety guards for no_trace Safety guards (trait shenanigans) guarantees safety usage of `no_trace` * Port canvas_traits to no_trace * Port servo_media to no_trace * Port net_traits to no_trace * Port style to no_trace * Port webgpu to no_trace * Port script_traits to no_trace * Port canvas_traits, devtools_traits, embedder_traits, profile_traits to no_trace * unrooted_must_root lint in seperate file * Add trace_in_no_trace_lint as script_plugin * Composable types in must_not_have_traceable * Introduced HashMapTracedValues wrapper * `HashMap<NoTrace<K>,V>`->`HashMapTracedValues<K,V>` * Port rest of servo's types to no_trace * Port html5ever, euclid, mime and http to no_trace * Port remaining externals to no_trace * Port webxr and Arc<Mutex<_>> * Fix spelling in notrace doc
* Implement :valid :invalid pseudo classes (#26729)John Poge II2023-07-211-12/+32
| | | Signed-off-by: Martin Robinson <mrobinson@igalia.com>
* Support arbitrary protos when wrapping DOM objects with constructors.Josh Matthews2023-05-281-1/+4
|
* Further changes required by ServoOriol Brufau2023-05-191-1/+1
|
* Update document focus when element focusability changes.Josh Matthews2020-06-151-0/+1
|
* Make clicking on an element request focus for focusable elements.Josh Matthews2020-06-151-3/+1
|
* Form constraints validationteapotd2020-04-021-2/+99
|
* Introduce more layout helpers to make selection_for_layout be safeAnthony Ramine2020-04-011-6/+12
|
* Introduce <LayoutDom<Element>>::focus_stateAnthony Ramine2020-04-011-1/+1
|
* Move unsafe code out of <LayoutDom<HTMLTextAreaElement>>::value_for_layoutAnthony Ramine2020-04-011-10/+19
|
* Introduce <LayoutDom<Element>>::attrs()Anthony Ramine2020-03-311-12/+6
| | | | | | This safe method is the basic block to access element attributes from layout. We reuse it in the other attr-related layout methods to remove a pretty big source of rampant unsafe code between script and layout.
* Merge RawLayoutElementHelpers into LayoutElementHelpersAnthony Ramine2020-03-311-3/+3
|
* Make LayoutHTMLTextAreaElementHelpers::value_for_layout safeAnthony Ramine2020-03-311-13/+12
|
* Give a lifetime parameter to LayoutDomAnthony Ramine2020-03-281-1/+1
|
* Add trait DomObjectWrap to provide WRAP functionYUAN LYU2020-03-201-2/+0
|
* Rearrange directionality algorithm functionsDmitry Kolupaev2020-02-251-6/+9
|
* Implement dirname for form submit and directionality for elementDmitry Kolupaev2020-02-251-0/+9
|
* Names should now be consistently atomsPatrick Shaughnessy2020-02-131-1/+1
|
* Labels are a live list in tree orderPatrick Shaughnessy2020-01-061-3/+3
|
* ISSUE-20455: introduce stronger types for textinput indexingThomas Delacour2019-05-161-5/+10
|
* Introduce BindContext with in_doc and connected flagsFernando Jiménez Moreno2019-04-261-3/+5
| | | | Fix some is_in_doc -> is_connected mistakes
* Add is_connected flag to node and use it to replace most uses of is_in_docFernando Jiménez Moreno2019-04-261-2/+2
|
* Auto merge of #22224 - pyfisch:composition-webdriver, r=noxbors-servo2018-11-201-0/+17
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Forward WebDriver CompositionEvent Dispatch composition events in JS. Insert characters from composition events to text input. CompositionEvents currently can only be created by WebDriver and not by embedders. <!-- Please describe your changes on the following line: --> --- <!-- 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 - [ ] These changes fix #__ (github issue number if applicable). <!-- Either: --> - [ ] 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/22224) <!-- Reviewable:end -->
| * Forward WebDriver CompositionEventPyfisch2018-11-191-0/+17
| | | | | | | | | | | | | | | | Dispatch composition events in JS. Insert characters from composition events to text input. CompositionEvents currently can only be created by WebDriver and not by embedders.
* | Update MPL license to https (part 3)Jan Andre Ikenmeyer2018-11-191-1/+1
|/
* Unify the task source and task canceller APIAgustin Chiappe Berrini2018-11-141-7/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | I moved away from the `Window` struct all the logic to handle task sources, into a new struct called `TaskManager`. In a happy world, I'd be able to just have there two functions, of the types: ```rust fn task_source<T: TaskSource>(&self, name: TaskSourceName) -> Box<T> fn task_source_with_canceller<T: TaskSource>(&self, name: TaskSourceName) -> (Box<T>, TaskSourceCanceller) ``` And not so much duplicated code. However, because TaskSource can't be a trait object (because it has generic type parameters), that's not possible. Instead, I decided to reduce duplicated logic through macros. For reasons[1], I have to pass both the name of the function with canceller and the name of the function without, as I'm not able to concatenate them in the macro itself. I could probably use `concat_idents` to create both types already defined and reduce the amount of arguments by one, but that macro is nightly only. At the same time, not being able to declare macros inside `impl` forces me to pass `self` as an argument. All this makes this solution more verbose than it would be ideally. It does reduce duplication, but it doesn't reduce the size of the file. [1](https://github.com/rust-lang/rust/issues/29599)
* `cargo fix --edition-idioms`Simon Sapin2018-11-081-2/+2
|
* Reorder importsPyfisch2018-11-061-2/+2
|
* Sort `use` statementsSimon Sapin2018-11-061-1/+1
|
* `cargo fix --edition`Simon Sapin2018-11-061-27/+27
|
* Format script componentchansuke2018-09-191-68/+108
|
* textarea minLength/maxLengthtigercosmos2018-06-181-2/+47
|
* add TextLengthtigercosmos2018-06-151-0/+5
|
* support textarea clonetigercosmos2018-06-071-1/+14
|
* Correct default selectionStart and selectionEndpaavininanda2018-02-231-4/+2
|
* Revert "Correct default Selectionstart and SelectionEnd"paavininanda2018-02-231-27/+25
| | | | This reverts commit b2c1f89b932a72f9e0110c17adde33647e84c902.
* Disallow mutating the internals of TextInputJon Leighton2018-02-161-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | The TextInput::assert_ok_selection() method is meant to ensure that we are not getting into a state where a selection refers to a location in the control's contents which doesn't exist. However, before this change we could have a situation where the internals of the TextInput are changed by another part of the code, without using its public API. This could lead to us having an invalid selection. I did manage to trigger such a situation (see the test added in this commit) although it is quite contrived. There may be others that I didn't think of, and it's also possible that future changes could introduce new cases. (Including ones which trigger panics, if indexing is used on the assumption that the selection indices are always valid.) The current HTML specification doesn't explicitly say that selectionStart/End must remain within the length of the content, but that does seems to be the consensus reached in a discussion of this: https://github.com/whatwg/html/issues/2424 The test case I've added here is currently undefined in the spec which is why I've added it in tests/wpt/mozilla.
* Correct default Selectionstart and SelectionEndpaavininanda2018-02-101-25/+30
|
* Refactor implementation of TextControlJon Leighton2018-01-301-18/+17
| | | | | | | | | | | | | | | | | The intention here is to make the flow more explicit. I.e. rather than calling `self.dom_select()` and relying on the programmer to know/realise that this method is provided by a trait, we call `self.selection().dom_select()` and the programmer can inspect the definition of `self.selection()` to follow the code. This came out of a discussion with KiChjang here: https://github.com/servo/servo/pull/19544#discussion_r156167044 Note that I tried to make "selection" be a member field of HTML{Input,TextArea}Element but it opened up a whole can of worms with lifetimes, so it seemed simpler to not do that since it is not essential for this code to work.
* Steps 7-9 of the input type change algorithmJon Leighton2018-01-261-2/+2
| | | | | | | | | | Spec: https://html.spec.whatwg.org/multipage/input.html#input-type-change In short, this resets the selection to the start of the field when the type has changed from one which doesn't support the selection API to one that does. I couldn't see an existing WPT test covering this.
* Implement setRangeText APIJon Leighton2018-01-261-7/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.)
* Fix clearing the selection when value is changedJon Leighton2018-01-261-2/+2
| | | | | | | | | | | | | 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.)
* Fix selection{Start,End} when selectionDirection is "backward"Jon Leighton2018-01-261-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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).
* Support the select() method on input/textareaJon Leighton2018-01-261-0/+9
| | | | Issue #19171
* Properly handle CR in textarea placeholders (fixes #19717)Anthony Ramine2018-01-101-7/+9
|
* Handle cases where selection API doesn't applyJon Leighton2017-12-081-14/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Move selection to end when textarea value is assignedJon Leighton2017-11-251-3/+18
| | | | Issue #19171
generated by cgit v1.2.3 (git 2.25.1) at 2025-04-30 18:47:02 +0000