Autofocused form field not typed into consistently

[Floriferous]

The first field of some of our forms has an autofocus attribute on it, to help users type immediately instead of having to focus the field manually.

We've seen some inconsistencies when typing into this field, depending on how we get it:

// JSX sample
<form>
  <input autoFocus name="input1" />
  <input name="input2" />
</form>

When this form appears, the focus is therefore set on the input1 field.

When writing tests:

// In this variant, the input1 is not filled properly on circle CI, locally it works well
cy.get('input[name=input1]').type('Some longer text ');
cy.get('input[name=input2]').type('123456789{enter}');

// This one seems to work reliably
cy.focused().type('Some longer text ');
cy.get('input[name=input2]').type('123456789{enter}');

Current behavior:

The text typed into the autofocused field is not written entirely when running on circle CI, works locally.

Desired behavior:

Both variants of getting and typing into the field should work reliably both locally and on the CI.

[Floriferous]

Nevermind, the focused() variant is also unstable and just failed on me.

[brian-mann]

I'm going to guess that we're going to need a reproducible example in this case, as this likely has to do with things your application is doing under the hood. I'm thinking that perhaps during the cy.type(...) it is re-rendering the JSX and losing some of the keys - because as we type, react sets the internal state asynchronously.

Can you please provide a simple reproducible example of this happening? Try running in Electron locally.

[jennifer-shehane]

I've confirmed that this works both in Chrome and Electron for standard input (no React) with autofocus="true"

We use autoFocus={true} on many of our own jsx components and have not encountered any of these problems. Are you calling 'focus' somewhere manually within your component?

[Floriferous]

Off-topic:

I tried to prepare a reproduction, but I ran into a huge mess trying to edit the React Todo MVC and quit. It'd be helpful to have better starting repos for reproduction and just playing around.

Like:

• react-cypress-starter
• react-vue-starter
• react-webpack-starter

It's always a bit painful to set things up when you just want to copy paste a few lines of JS from your source code to prepare a reproduction.

I'll try again later.

[bahmutov]

@Floriferous I am not sure what you are suggesting here. For us to make React + Cypress starter scaffolding? And Vue app + Cypress scaffolding? I would not want to maintain these, instead I would love every scaffolding author to add Cypress as an option. Like Vue CLI v3 did or Nx https://docs.cypress.io/plugins/index.html#framework-tooling

[Floriferous]

Yes that scaffolding is exactly what I mean :)

Sure it requires some work, and obviously it is in Cypress interest to be the "default" option when people start playing with JS frameworks, but that might be much more difficult to do, than to build a few cookie-cutter repos.

I mention this, because material-ui is a good example of this, their issue template contains 2 links to codesandboxes where you can immediately get going with your reproduction (make it raw to see the commented links):
https://github.com/mui-org/material-ui/edit/master/.github/ISSUE_TEMPLATE/1.bug.md

I understand cypress doesn't fit inside a code-sandbox, but still it's very welcome :)

From what I see on this repo and on other E2E frameworks' repos, you're getting a huge amount of tickets because the problem-space is so big. Making it easier for the people who come here to give you a reproduction isn't too bad of an objective imho! It'd be interesting to track the % of new issues that contain a reproduction and see how it evolves over time.

---

As far as this issue is concerned, I fixed it by waiting for 2 seconds..

What happens in the test is as follows:

• Form appears, focus is set on the first field
• Cypress starts typing
• Focus is being taken away from the field before cypress has finished typing
  • No idea what is causing this, as it does not happen outside of cypress in the CI
• Focus is set back on the field
• Cypress moves on to the next field of the form

I'll close this!

[jennifer-shehane]

@Floriferous I would love to make providing a reproducible example easier for people opening issues.

Looking at the material-ui issue templates, they are great - but also looking at their last 10 opened issues, only 4/10 of those used the provided issue template, which is similar to what we experience at Cypress.

• Some people will always, undoubtedly provide great detail with a reproducible example.
• Some people will need some guidance on what they need to provide us and how to do that.
• Some people will never follow the provided template or spend more than 10 minutes describing their issue (which is understandable, everyone needs more time!)

I would be more enthusiastic about creating our own code sandboxes if this were not the case, but I do feel like the effort required to make it and maintain it may not be worth the gain at this stage.

[bahmutov]

@jennifer-shehane I agree with you. Maybe our issue template could point at

• cypress-test-tiny (with instructions)
• cypress-example-kitchensink
• cypress-example-todomvc

As starting points?

[Floriferous]

@jennifer-shehane That's very insightful data, cool! I do wonder if both repos have the same audience though, I wonder if material-ui has more beginner-type issues because it's one of the first packages you play with as you come to React. Whereas I would expect cypress to have a bit more experienced devs raising issues?

I can tell from my experience that the more experienced I become, the more reproductions I provide, because it is much easier to do than when you're a junior as it's really hard to tell whether a bug is your fault or the library's.