aboutsummaryrefslogtreecommitdiffstats
path: root/components/script/dom/textcontrol.rs
Commit message (Collapse)AuthorAgeFilesLines
* Include `WebViewId` into EmbedderMsg variants where possible (#35211)Delan Azabani2025-01-301-4/+3
| | | | | | | | | | | | | | | | | `EmbedderMsg` was previously paired with an implicit `Option<WebViewId>`, even though almost all variants were either always `Some` or always `None`, depending on whether there was a `WebView involved. This patch adds the `WebViewId` to as many `EmbedderMsg` variants as possible, so we can call their associated `WebView` delegate methods without needing to check and unwrap the `Option`. In many cases, this required more changes to plumb through the `WebViewId`. Notably, all `Request`s now explicitly need a `WebView` or not, in order to ensure that it is passed when appropriate. Signed-off-by: Delan Azabani <dazabani@igalia.com> Co-authored-by: Martin Robinson <mrobinson@igalia.com>
* script: Limit public exports. (#34915)Josh Matthews2025-01-101-12/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * script: Restrict reexport visibility of DOM types. Signed-off-by: Josh Matthews <josh@joshmatthews.net> * script: Mass pub->pub(crate) conversion. Signed-off-by: Josh Matthews <josh@joshmatthews.net> * script: Hide existing dead code warnings. Signed-off-by: Josh Matthews <josh@joshmatthews.net> * Formatting. Signed-off-by: Josh Matthews <josh@joshmatthews.net> * Fix clippy warnings. Signed-off-by: Josh Matthews <josh@joshmatthews.net> * Formatting. Signed-off-by: Josh Matthews <josh@joshmatthews.net> * Fix unit tests. Signed-off-by: Josh Matthews <josh@joshmatthews.net> * Fix clippy. Signed-off-by: Josh Matthews <josh@joshmatthews.net> * More formatting. Signed-off-by: Josh Matthews <josh@joshmatthews.net> --------- Signed-off-by: Josh Matthews <josh@joshmatthews.net>
* script: Expose `NodeTraits::owner_global` / `Window::as_global_scope` (#34843)Martin Robinson2025-01-071-1/+1
| | | | | | | | | | | Expose two new helpers and start using them as much as possible. - `NodeTraits::owner_global`: which gets the `GlobalScope` that currenty owns a `Node`. This may be different than `.global()` in the case that the `Node` was adopted by a different `Document`. - `Window::as_global_scope`: A helper to avoid having to cast so much when treating a `Window` like a `GlobalScope`. Signed-off-by: Martin Robinson <mrobinson@igalia.com>
* script: Move `TaskManager` to `GlobalScope` (#34827)Martin Robinson2025-01-041-3/+2
| | | | | | | | | | | | | | | | | | | | This is a simplification of the internal `TaskQueue` API that moves the `TaskManager` to the `GlobalScope` itself. In addition, the handling of cancellers is moved to the `TaskManager` as well. This means that no arguments other than the `task` are necessary for queueing tasks, which makes the API a lot easier to use and cleaner. `TaskSource` now also keeps a copy of the canceller with it, so that they always know the proper way to cancel any tasks queued on them. There is one complication here. The event loop `sender` for dedicated workers is constantly changing as it is set to `None` when not handling messages. This is because this sender keeps a handle to the main thread's `Worker` object, preventing garbage collection while any messages are still in flight or being handled. This change allows setting the `sender` on the `TaskManager` to `None` to allow proper garbabge collection. Signed-off-by: Martin Robinson <mrobinson@igalia.com>
* script: Expose node helpers as `NodeTraits` and give more descriptive names ↵Martin Robinson2025-01-031-2/+2
| | | | | | | | | | | | | (#34832) This puts a few commonly used `Node` helpers into a trait (`NodeTraits`) and gives them more descriptive names and documentation. The renames: - `document_from_node` -> `NodeTraits::owner_document` - `window_from_node` -> `NodeTraits::owner_window` - `stylesheets_owner_from_node<T:` -> `NodeTraits::stylesheet_list_owner` - `containing_shadow_root` -> `NodeTraits::containing_shadow_root` Signed-off-by: Martin Robinson <mrobinson@igalia.com>
* fix(clippy): Clippy suggestions in components/script/dom/* (#33072)Jose Monagas2024-08-151-1/+1
| | | | Signed-off-by: Jose T. Monagas <josetmonagas@proton.me> Co-authored-by: Jose T. Monagas <josetmonagas@proton.me>
* fix redundant closures in component/script/dom (#31917)Ekta Siwach2024-03-281-1/+1
| | | | | | | | | | | | | * fixed unnecessary conversions * resolved conflicts * resolved conflicts * fix redundant closures in component/script/dom * resolved conflicts * fixed formatting
* clippy: Fix many warnings in `components/script` (#31717)Richard Dushime2024-03-191-2/+2
| | | | | | | | | | | | | | | | | * Fix Several clippy warnings * Fix Build errors * Fix Unused import * Fix requested changes * Fix rustfmt * Minor fixes --------- Co-authored-by: Martin Robinson <mrobinson@igalia.com>
* rustdoc: Fix many rustdoc errors (#31147)Martin Robinson2024-01-221-1/+1
| | | | This fixes many rustdoc errors that occur due to raw URLs in rustdoc comments as well as unescaped Rust code that should be in backticks.
* Strict import formatting (grouping and granularity) (#30325)Samson2023-09-111-1/+2
| | | | | * strict imports formatting * Reformat all imports
* ISSUE-20455: introduce stronger types for textinput indexingThomas Delacour2019-05-161-4/+7
|
* 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)
* Reorder importsPyfisch2018-11-061-1/+1
|
* Sort `use` statementsSimon Sapin2018-11-061-1/+1
|
* `cargo fix --edition`Simon Sapin2018-11-061-9/+9
|
* Format script componentchansuke2018-09-191-9/+26
|
* Disallow mutating the internals of TextInputJon Leighton2018-02-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Refactor implementation of TextControlJon Leighton2018-01-301-59/+78
| | | | | | | | | | | | | | | | | 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.
* Implement setRangeText APIJon Leighton2018-01-261-8/+121
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.)
* Don't fire select event when selection hasn't changedJon Leighton2018-01-261-8/+13
|
* Fix selection{Start,End} when selectionDirection is "backward"Jon Leighton2018-01-261-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/+12
| | | | Issue #19171
* Handle cases where selection API doesn't applyJon Leighton2017-12-081-24/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Handle setting selectionStart to be > selectionEndJon Leighton2017-11-251-1/+10
|
* Extract common text control selection codeJon Leighton2017-11-181-0/+78
The API for text control selection is the same for both <input> and <textarea>: https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#textFieldSelection Before this change, they had similar but not identical implementations with duplicate code. Now there is a common TextControl trait which contains the implementation used by both. As a result, some previously failing tests now pass.
generated by cgit v1.2.3 (git 2.25.1) at 2025-04-26 00:11:34 +0000