Skip to content
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

Merged
merged 8 commits into from
Mar 15, 2019

Conversation

silviuaavram
Copy link
Contributor

@silviuaavram silviuaavram commented Jan 7, 2019

PR close #2033 by implementing handlers for Home and End in function type.

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.

@CLAassistant
Copy link

CLAassistant commented Jan 7, 2019

CLA assistant check
All committers have signed the CLA.

@jennifer-shehane
Copy link
Member

@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/

@jennifer-shehane jennifer-shehane requested a review from kuceb January 7, 2019 17:18
@kuceb
Copy link
Contributor

kuceb commented Jan 7, 2019

Hi @silviuavram, thanks for this PR.

You pulled the selection utils from #2436 correct? Looks pretty good, however

for home and end, we need to take into account whether focused element is an input, and if not, set scrollTop=0 or scrollHeight on the innermost scrollable el.

options.input = false
options.setKey = "{home}"
@ensureKey el, null, options, ->
$selection.moveCursorToStart(el)
Copy link
Contributor

@kuceb kuceb Jan 7, 2019

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)
Copy link
Contributor

@kuceb kuceb Jan 7, 2019

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

Copy link
Contributor Author

@silviuaavram silviuaavram Jan 8, 2019

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 ?

Copy link
Contributor

@kuceb kuceb Jan 9, 2019

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)?

Copy link
Contributor Author

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

Copy link
Contributor

@kuceb kuceb Jan 15, 2019

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})

Copy link
Contributor Author

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

Copy link
Contributor

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?

Copy link
Contributor Author

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!

@silviuaavram
Copy link
Contributor Author

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!

kentcdodds pushed a commit to downshift-js/downshift that referenced this pull request Jan 8, 2019
**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 -->
@silviuaavram
Copy link
Contributor Author

@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!

@kuceb
Copy link
Contributor

kuceb commented Jan 23, 2019

@silviuavram LGTM. @brian-mann can this go in 3.2?

We will need to update the docs for cy.type as well

@jennifer-shehane
Copy link
Member

Opened an issue for adding docs for {home} and {end} to supported sequences here: cypress-io/cypress-documentation#1344

@jennifer-shehane jennifer-shehane changed the base branch from develop to v3.2.0 January 24, 2019 18:29
@brian-mann brian-mann changed the title Fix Issue 2033 Add {home} and {end} to cy.type() Jan 24, 2019
@silviuaavram
Copy link
Contributor Author

What happened to this one? Are these changes added already or something else? :)

@jennifer-shehane
Copy link
Member

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.

@jennifer-shehane jennifer-shehane changed the base branch from v3.2.0 to develop March 14, 2019 03:23
@brian-mann brian-mann merged commit 2122320 into cypress-io:develop Mar 15, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add support for {home} and {end} special character sequences
5 participants