aboutsummaryrefslogtreecommitdiffstats
path: root/tests/unit/script/textinput.rs
Commit message (Collapse)AuthorAgeFilesLines
* Allow deletion from overflowed textinputteapotd2020-01-101-0/+22
|
* Restore DummyClipboardContext for textinput.rs testsMichal Mieczkowski2019-06-151-1/+22
|
* ISSUE-20455: introduce stronger types for textinput indexingThomas Delacour2019-05-161-135/+236
|
* Fixed bug in textinput::adjust_vertical concerning selection_origin updateDenis Merigoux2018-12-221-0/+4
| | | | | | | | This bug was discovered using the F* formal verification framework. Style changes (match -> if let) Replace if let Some(_) by .is_some()
* Correct select allPyfisch2018-11-071-0/+10
| | | | | Fixes assertion failure. Set selection direction forward on select all.
* Reorder importsPyfisch2018-11-061-1/+1
|
* Format remaining filesPyfisch2018-11-061-31/+71
|
* Use keyboard-types cratePyfisch2018-10-071-13/+12
| | | | | | | | | | | | | Have embedders send DOM keys to servo and use a strongly typed KeyboardEvent from the W3C UI Events spec. All keyboard handling now uses the new types. Introduce a ShortcutMatcher to recognize key bindings. Shortcuts are now recognized in a uniform way. Updated the winit port. Updated webdriver integration. part of #20331
* Correct default selectionStart and selectionEndpaavininanda2018-02-231-1/+6
|
* Revert "Correct default Selectionstart and SelectionEnd"paavininanda2018-02-231-6/+2
| | | | This reverts commit b2c1f89b932a72f9e0110c17adde33647e84c902.
* Disallow mutating the internals of TextInputJon Leighton2018-02-161-117/+114
| | | | | | | | | | | | | | | | | | | | | | | | | | 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-3/+7
|
* Changed offset_to_text_point function and added unit tests for the samepaavininanda2018-02-071-0/+28
|
* Fix selection{Start,End} when selectionDirection is "backward"Jon Leighton2018-01-261-11/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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).
* Handle cases where selection API doesn't applyJon Leighton2017-12-081-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Bump bitflags to 1.0 in every servo crateBastien Orivel2017-10-301-13/+11
|
* Backed out changeset e64e659c077d: servo PR #18809 and revendor for reftest ↵Gecko Backout2017-10-191-11/+13
| | | | | | failures, e.g. in layout/reftests/bugs/392435-1.html. r=backout on a CLOSED TREE Backs out https://github.com/servo/servo/pull/18809
* Update bitflags to 1.0 in every servo crateBastien Orivel2017-10-191-13/+11
| | | | | It still needs dependencies update to remove all the other bitflags versions.
* Conditionally import values for mac tests.Josh Matthews2017-07-271-0/+2
|
* Clean up warnings in script unit tests.Josh Matthews2017-07-261-2/+1
|
* Auto merge of #15822 - charlesvdv:unicode-panic, r=emiliobors-servo2017-04-161-0/+10
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Correct unicode handling for text input <!-- Please describe your changes on the following line: --> Allow proprer handling of unicode sequence in text input. --- <!-- 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 - [x] These changes fix #15819 <!-- Either: --> - [ ] There are tests for these changes OR - [ ] These changes do not require tests because _____ <!-- 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/15822) <!-- Reviewable:end -->
| * add test for text input unicode handlingcharlesvdv2017-04-161-0/+10
| |
* | new keyboard shortcuts inside text inputClement Miao2017-04-071-4/+110
|/
* Introduce a script::test module to expose the APIs needed for unit tests.Ms2ger2016-12-221-1/+1
|
* Implement minlength for text inputsTaryn Hill2016-09-211-2/+17
|
* Reorder `use` statementsUK9922016-09-091-1/+1
|
* Add unit test for setting selection with selection directionConnor Brewster2016-07-061-0/+23
|
* Make textinput handle actual key values. Don't restrict character values to ↵Josh Matthews2016-07-061-1/+1
| | | | a single byte.
* Move DOMString back to scriptAnthony Ramine2016-05-241-1/+1
| | | | This entirely removes the 'non-geckolib' feature of the util crate.
* Implement HTMLTextArea.setSelectionRangeAlberto Corona2016-04-171-13/+23
|
* TextInput::max_length should be in code units, not bytesMatt Brubeck2016-04-021-0/+49
|
* Find the correct column index in adjust_verticalMatt Brubeck2016-04-011-0/+13
|
* Use correct byte indices in replace_selectionMatt Brubeck2016-04-011-0/+9
|
* Fix delete_char when selection range is emptyMatt Brubeck2016-03-251-0/+7
| | | | | An empty selection range should be treated the same as no selection. Fixes browserhtml/browserhtml#930.
* Resolves long-running merge conflictsSam Gibson2015-12-031-3/+3
|
* Adds a test for set_content to ignore max_lengthSam Gibson2015-12-031-0/+10
|
* Adds support for input element's maxlength attrSam Gibson2015-12-031-3/+104
| | | | | servo/servo#7320 servo/servo#7004
* Replaced DOMString constructor by conversion functions.Alan Jeffrey2015-11-121-6/+5
| | | | | | Replaced DOMString(...) by DOMString::from(...). Replaced ....0 by String::from(...). Removed any uses of .to_owner() in DOMString::from("...").
* Make DOMString a newtype around String, rather than a typedef.Ms2ger2015-11-041-5/+8
| | | | | | | | | | This should make it somewhat easier to experiment with alternative representations in the future. To reduce churn, this commit leaves the String field public, though. Also, this will allow us to use the default String type to represent the IDL USVString type, which explicitly forbids unpaired surrogates, ans as such is a better match to the Rust String type.
* Create a helper function to create TextInput structs in its unit test.Ms2ger2015-11-041-21/+21
|
* Fix reported test-tidy errors for unmerged import blocksBrandon Fairchild2015-09-191-5/+3
| | | | This merges import blocks that were reported by tidy as unmerged.
* Auto merge of #7459 - Mylainos:Issue-#7365, r=jdmbors-servo2015-09-011-0/+54
|\ | | | | | | | | | | | | | | | | | | | | | | Issue #7365 : test cursor position after clearing selection In textinput test if the cursor is at the correct position when clearing a selection by press an arrow key. edit_point is always at the end of the selection, should I test when it's at the beginning ? <!-- Reviewable:start --> [<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/7459) <!-- Reviewable:end -->
| * Issue #7365 : test for cursor position after clearing selectionHugo Thiessard2015-08-311-0/+54
| |
* | make test-tidy check that = have space after themerneyja2015-09-011-4/+4
|/
* Refactor script::textinput to count UTF-8 bytes rather than code points.Simon Sapin2015-08-281-4/+19
|
* sort all usesJohann Tuffe2015-08-201-1/+1
|
* Add set_clipboard_context function and relevant plumbing. Use Option more ↵Avi Weinstock2015-07-291-2/+2
| | | | consistantly (less unwraps) in textinput's selection handling.
* Reduce max line length from 150 to 120 charactersCorey Farwell2015-05-241-4/+8
| | | | Part of https://github.com/servo/servo/issues/6041
* Fix test_clipboard_paste to pass on Mac OS.Avi Weinstock2015-05-061-2/+13
|
* Made the clipboard-related functionality in TextInput more testable. Added ↵Avi Weinstock2015-05-061-13/+23
| | | | test_clipboard_paste to the "test-unit" suite.
generated by cgit v1.2.3 (git 2.25.1) at 2025-06-10 00:57:05 +0000