feat(pointer)!: change selection per pointer #763
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
BREAKING CHANGE: `userEvent.type` does no longer move the cursor if used with `skipClick=false` and without `initialSelectionStart`.
Codecov Report
@@ Coverage Diff @@
## alpha #763 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 64 65 +1
Lines 1245 1323 +78
Branches 469 510 +41
=========================================
+ Hits 1245 1323 +78
Continue to review full report at Codecov.
|
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit 37490aa:
|
ph-fritsche
force-pushed
the
feat-mousedownselect
branch
from
f1c82c8
to
835801f
Compare
ph-fritsche
changed the title
mousedown
|
🎉 This PR is included in version 14.0.0-alpha.3 🎉 The release is available on: Your semantic-release bot 📦🚀 |
3 tasks
ph-fritsche
added a commit
that referenced
this pull request
Nov 28, 2021
* feat!: change input selection on `mousedown` * change selection on different elements and with offset * stop moving selection after pointerup BREAKING CHANGE: `userEvent.type` does no longer move the cursor if used with `skipClick=false` and without `initialSelectionStart`.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
BREAKING CHANGE:
userEvent.typedoes no longer move the cursorif used with
skipClick=falseand withoutinitialSelectionStart.What:
The browser changes the selection range on
mousedownevents andmousemoveevents if the mouse button is still pressed.We can not apply the exact behavior like the browser does, as it moves the cursor to the character closest to the
mousedownevent which we can not determine in a no-layout environment.This PR tries an approximation of the browser behavior.
Why:
E.g. in the browser performing a
dblClickon an element<input value="abc"/>selects the input and the next keystroke overrides it.But this was not the case with
userEvent.How:
Treat every mouse event as if it happens in the area after the
textContent/value.In
userEvent.typewe moved the selection if the selectionRange was at the default0, 0. So thatuserEvent.type(el, 'text')would append thetextper default. This was determined the expected behavior by the user.I think that might have been the result of
mousedownmoving the cursor in the browser - when focussing an input by clicking in the blank area after the input value.I think with this change it is reasonable to change this default behavior as our
clickintypenow does exactly this.I also removed the check of selection range position if the user calls
userEvent.typewithinitialSelectionStartso it is always applied if given.This PR introduces two new options to the pointer actions:
pointer({node: E})treatsEas the DOM node containing the character closest to the pointer actionpointer({offset: 5})treats thetextContent/valueposition5as the character closest to the pointer actionoffsetrepresents the DOM offset insteadChecklist:
Additional information
See this the scenario regarding the gap between the user interaction as it might be perceived by our users and the actual events in the browser:
=> The pointer event target is
E1and the corresponding selection position isnode: E1->#text, offset: 0=> The pointer event target is
Cand the corresponding selection position isnode: E1->#text, offset: 0=> The pointer event target is
Cand the corresponding selection position isnode: C, offset: 1Even if we don't implement every aspect of it right away, we need a solution what input our API should accept that can be translated into these results.
The blunt solution would be to expect our users to supply the correct node and offset. But I feel that should only be a fallback for such complicated edge cases.