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

app code that programmatically calls focus() doesn't work if the browser isn't the active window #3639

Closed
fr0 opened this issue Mar 4, 2019 · 5 comments
Labels
type: duplicate This issue or pull request already exists

Comments

@fr0
Copy link

fr0 commented Mar 4, 2019

Current behavior:

Try the following test:

      cy.visit('https://typescript-625eku.stackblitz.io');
      cy.get('#box').click();
      cy.wait(3000);
      cy.get('#box').trigger('keydown', {key: 'ArrowDown'});
      cy.get('#myInput').should('have.class', 'bright');

During the cy.wait, try either giving the browser focus, or giving another application focus. The test will pass/fail depending on this.

Desired behavior:

I think that focus behavior should not be this flaky. I frequently use cypress open and am typing in my editor while tests are running.

Steps to reproduce: (app code and test code)

https://stackblitz.com/edit/typescript-625eku?file=index.ts

Versions

3.1.5

@fr0
Copy link
Author

fr0 commented Mar 4, 2019

Oddly enough, if you activate the browser window after the focus() method has been called, but before the test timeout occurs, it will pass. Looks like something's being queued up for when the browser is activated in that case.

@jennifer-shehane
Copy link
Member

cc @bkucera - We've worked a lot on this focus behavior already and agree it should not be flaky.

@kuceb
Copy link
Contributor

kuceb commented Mar 7, 2019

this is a duplicate of #1176 and is fixed in #2982

However I do think this issue title is more helpful in describing the bug, so thank you @fr0

@kuceb kuceb closed this as completed Mar 7, 2019
@kuceb kuceb added the type: duplicate This issue or pull request already exists label Mar 7, 2019
@fr0
Copy link
Author

fr0 commented Mar 7, 2019

Glad to know it's going to be fixed. Can I ask the obligatory "when can I have the fix?" :D

@kuceb
Copy link
Contributor

kuceb commented Mar 7, 2019

@fr0 pending code review, most likely 3.2.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: duplicate This issue or pull request already exists
Projects
None yet
Development

No branches or pull requests

3 participants