-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add {home} and {end} to cy.type() #3071
Conversation
@silviuavram Thanks for signing the CLA, unfortunately the author of the commits does not match the email address on your GitHub account. Our CLA bot gets confused when they don't match. Here are some solutions to fixing when commits are linked to the wrong user: https://help.github.com/articles/why-are-my-commits-linked-to-the-wrong-user/ |
Hi @silviuavram, thanks for this PR. You pulled the selection utils from #2436 correct? Looks pretty good, however for |
options.input = false | ||
options.setKey = "{home}" | ||
@ensureKey el, null, options, -> | ||
$selection.moveCursorToStart(el) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if not an input, set scrollTop=0
on innermost scrollable el
options.input = false | ||
options.setKey = "{end}" | ||
@ensureKey el, null, options, -> | ||
$selection.moveCursorToEnd(el) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if not an input, set scrollTop=el.scrollHeight` on innermost scrollable el
edit: we can forsake this default action, unless someone expresses desire for it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
a bit confusing for me.
i know that when you use Home and End, and you are not in input/textarea, it should scroll to top/bottom of page.
however there is a similar story with Up Arrow and Down Arrow, they scroll up/down a little bit.
that being said, I don't see any scrolling stuff in their handlers here. it's the reason I did not add anything to my handlers either.
what am i missing @bkucera ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see what you're saying about up/down arrow not currently scrolling the page. We probably wouldn't end up fulfilling that default action, and only fulfill the default action of the {home} and {end} keys inside of text editables
However, the selection.modify API isn't available in IE11 (even though there are ways to polyfill it) so we should be hesitant to use it. @silviuavram is your app preventing default on the home key press, or do you need the default action (move to end of line)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Resumed working on this and renamed a variable as it was used for two reasons in the same function: start
. This is what happens when you are not paying attention...
Anyway, about the {home} and {end} keys, my use is to create e2e tests for a Dropdown, and the scenario tests that, with focus on Edit Text and Menu open, Home highlights the first option in the menu, while End highlights the last one.
I want to fully understand how this works in keyboard.coffee
. If there is an element focused, we call, for example, $selection.moveCursorToLineStart(el)
, to simulate the cursor behaviour for Home/End inside an <input>
or <textarea>
? If no focused element, what happens then? Are the Home/End default behaviours happening anyway? (scrolling to the beginning/end of the page, if no input element is focused).
Or maybe point me to some documentation maybe that will be easier. And also since I mentioned pointing at stuff, I cannot find where to add unit tests for my changes. Can you also help me with this, please?
Thank you for your time! @bkucera
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@silviuavram yes, inside a text-editable (input, text-area, or contentedtiable), we send synthetic events and we move the cursor, if of course the event was not canceled on keydown
(taken care of for you)
if it's not a text-editable, we should send synthetic events but don't move the cursor, and just skip over the page scrolling for now. This would happen if you used cy.get('body').type(...)
for example.
Tests should go in packages/driver/test/cypress/integration/commands/actions/type_spec.coffee
and you could add a new describe
block testing the functionality of using permutations of cy.get('input/textarea/[contenteditable]/body').type({home}/{end})
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I started to add some unit tests. Will continue tomorrow. You can take a fast look to see if they're on the right track.
I also refactored the _moveCursorToLineStartOrEnd
method and used only selection.modify
to move that cursor, for everything (contenteditable, textarea, input). I don't think there is any reason to do some \n
search and move the cursor with setSelectionRange
after doing some math magic to locate the line start/end, right?
Hopefully if this is on the right track we can merge it soon. Thanks very much for the help! @bkucera
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@silviuavram sure, modern browsers support selection.modify so that's fine.
I believe you are referring to integration tests, not unit?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bkucera great to hear that.
As for the tests, I think I've added kind of unit tests. You can check now in type_spec.coffee
where I added for {home}
and {end}
. But please let me know if I need to add more and maybe point me to location. The test codebase is pretty massive.
Thank you very much for assistance!
Thanks everyone for the quick feedback, much appreciated! Will fix the issues you pointed out tomorrow and will also write the tests for the changes. Will come back to you afterwards! @bkucera I am not sure what you mean by your PR, maybe I am missing some context :) . The branch is branched out from latest develop, did not merge anything else in it. Let me know if I need any more information related to this, thanks! |
**What**: This PR aims to improve kb navigation inside the listbox by adding support for `Home` and `End`. These keys should highlight first / last element, if the listbox is visible. **Why**: Improves the component by adding another ARIA specification regarding kb navigation. **How**: Added event listeners for keydown on both `Home` and `End`, and added handlers for each, in which I've used variations for the `setHighlightedIndex` function. Also added event names for both kets. Also added UTs for these changes, and planning to add E2E Cypress tests too. These are already written, however Cypress does not support Home and End at the moment. I've created a PR for implementing this in their repo [here](cypress-io/cypress#3071). Those tests are currently commented. **Checklist**: - [ ] Documentation - [ ] Tests - [ ] Ready to be merged <!-- In your opinion, is this ready to be merged as soon as it's reviewed? --> - [ ] Added myself to contributors table <!-- this is optional, see the contributing guidelines for instructions -->
@bkucera please see my last comment. I've added unit tests and I think we're good to go after you also take another look. Thanks! |
@silviuavram LGTM. @brian-mann can this go in 3.2? We will need to update the docs for cy.type as well |
Opened an issue for adding docs for |
What happened to this one? Are these changes added already or something else? :) |
Oh no, I deleted the branch it was set to merge into, in an attempt to rename the branch. I didn't realize this would close the PRs against the deleted branch. What a mess. 😝 I will fix this. |
PR close #2033 by implementing handlers for
Home
andEnd
in functiontype
.I am creating a PR for Downshift library in which I am implementing keyboard handling for Home and End in the context of a Dropdown (Home highlights first option, End the last one). PR is here. I meant to write end-to-end tests as well. Since the repo uses Cypress, I found that it did not support
{home}
and{enter}
so I found this issue in your repo and am trying to fix it.Work is still in progress, I still mean to write UTs and E2Es. However, I appreciate early feedback on the implementation as well, since this could be my first commit in this repository.