fix: iFrame input focus should not cause blur if input already activeElement

[martynchamberlin]

• Closes iFrame elements that focus, when calling .type() are actually blurred (when Test Runner is not focused) #8111

User facing changelog

Fixed an issue where focusing on an input inside iFrame contents causes blur if the input was already selected.

Additional details

Here's a quick rundown on what's wrong and how this PR seeks to fix it.

We are looking to start using Cypress to integration-test our credit card checkout experience at Chess.com. Our payment vendor is Adyen and the way it works, each credit card input field is an iFrame coming from Adyen's server. Here's a screenshot with each iFrame annotated with a pink background:

When you complete the expiration month field, Adyen auto-tabs you to the expiration year field. When you complete that, Adyen auto-tabs you to the security code. When auto-tabbing, Adyen also auto-focuses on the <input> within each iFrame.

My integration test in part looks like this:

  cy.getFrame('encryptedExpiryMonth')
    .find('#encryptedExpiryMonth')
    .type('12');

  cy.getFrame('encryptedExpiryYear')
    .find('#encryptedExpiryYear')
    .type('25');

When .type() executes for each of these, this click event occurs:

cypress/packages/driver/src/cy/commands/actions/type.js

Line 401 in 7da2c4d

return cy.now('click', $elToClick, {

...which triggers this:

cypress/packages/driver/src/cy/mouse.js

Line 530 in 7da2c4d

const mouseDownPhase = mouse.down(fromElViewport, forceEl, pointerEvtOptionsExtend, mouseEvtOptionsExtend)

...which triggers this:

cypress/packages/driver/src/cy/mouse.js

Line 478 in 7da2c4d

focused.fireBlur($focused.get(0))

...which triggers this:

cypress/packages/driver/src/cy/focused.js

Line 126 in 7da2c4d

fireBlur($focused.get(0))

In other words, this focusing on an input that's already focused results in it blurring, which is the bug. In this scenario, this conditional here is evaluating true where it should be evaluating false:

cypress/packages/driver/src/cy/focused.js

Line 121 in 7da2c4d

if ($focused && $focused.get(0) !== el) {

That is because there's a hardcoded assumption here that the document in question is the top document, not the document that the element in question belongs to:

cypress/packages/driver/src/cy/focused.js

Line 224 in 7da2c4d

const { activeElement } = state('document')

By giving an optional argument to specify the document in the getFocused function, iFrames get better support in Cypress.

How has the user experience changed?

n/a

PR Tasks

• Have tests been added/updated? Maybe there's a way to get the idea at Add a failing test for iFrames cypress-test-tiny#61 incorporated into a test, although I'm still trying to figure out how to get that to fail on CI. In our more complex environment internally it certainly fails CI.

[cypress-bot]

Thanks for taking the time to open a PR!

• Create a Draft Pull Request if your PR is not ready for review. Mark the PR as Ready for Review when you're ready for a Cypress team member to review the PR.
• Become familiar with the Code Review Checklist for guidelines on coding standards and what needs to be done before a PR can be merged.

[CLAassistant]

All committers have signed the CLA.

[jennifer-shehane]

I did manually verify that this fixes the original issue. A test would be ideal...maybe someone else on the team has an idea on how to test this. @chrisbreiding @bkucera ?

[chrisbreiding]

I added a test. It's the repro one from the issue. Needed to try it out to make sure it would work. It did, so I figured I'd go ahead and commit it.

[martynchamberlin]

@chrisbreiding This test would fail in the develop branch apart from the changes in this PR. I can't figure out how to get the test to fail in develop because to reproduce, you have to blur the entire browser. Not sure that's programmatically possible. 🤔

[jennifer-shehane]

K, I found a way to make this break in the tests without manually focusing out. This basically breaks if you open DevTools, so we can have the Devtools auto open to make this test fail.

This will only work in Chrome, I don't know how to open devtools in Electron from preferences. This bug doesn't happen in Firefox, so we won't need a test for that. I think this is better than nothing.

@chrisbreiding I'm not sure what the best way is to have these preferences apply for a single spec run in our driver tests.

module.exports = (on, config) => {
  on('before:browser:launch', (browser = {}, launchOptions) => {
    if (browser.family === 'chromium' && browser.name !== 'electron') {
      // auto open devtools
      launchOptions.args.push('--auto-open-devtools-for-tabs')
    }

    return launchOptions
  })
}

[chrisbreiding]

I moved the test to be an e2e test so the open devtools could be applied to it. Don't think there's a way to do that individually for a driver test.

[jennifer-shehane]

Sorry, this test also depends on the Chrome browser being headed so I added that to the e2e test. I checked that the e2e test fails without this fix and passes with it and added some clarifying comments. 👍

[martynchamberlin]

Groovy. Thanks for all your help everyone! 💪