chore: Implement cross-domain sibling iframe

[chrisbreiding]

• Closes Multidomain: Create Sibling Bridge Iframe #16452

User facing changelog

N/A - only a partial feature of multidomain

Additional details

Adds a sibling iframe in which to run the cross-domain driver bundle. It's added dynamically when the AUT navigates to a second domain. Much is still hard-coded (domain needs to be localhost:3501), but further work will make it more dynamic.

Also includes a very rudimentary implementation of cy.switchToDomain.

PR Tasks

• Have tests been added/updated?
• N/A Has the original issue or this PR been tagged with a release in ZenHub? won't be released - going into a feature branch
• N/A Has a PR for user-facing changes been opened in cypress-documentation?
• N/A Have API changes been updated in the type definitions?
• N/A Have new configuration options been added to the cypress.schema.json?

[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.

[cypress]

---

Test summary

116 • 1 • 0 • 0 • 1

---

Run details

Project	cypress
Status	Errored
Commit	8dd089d
Started	Jun 4, 2021 8:14 PM
Ended	Jun 4, 2021 8:22 PM
Duration	07:48 💡
OS	Linux Debian - 10.8
Browser	Electron 89

View run in Cypress Dashboard ➡️

---

Flakiness

	cypress/integration/retries.ui.spec.js		1
1	runner/cypress retries.ui.spec > opens attempt on each attempt failure for the screenshot, and closes after test passes

---

This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. You can manage this integration in this project's settings in the Cypress Dashboard

[flotwig]

fn here will have the caveat that it doesn't have access to variables of parent lexical scopes, is this something that will be addressed or is it the plan to keep it that way?

[chrisbreiding]

Yes, it will be addressed in future work. This is a bare-minimum version of this command just to get things rolling.

[flotwig]

what's the difference b/t this and autoEnd? same comment

i think you can also update this in packages/driver/types/internal-types.d.ts if you don't want it to be public

[chrisbreiding]

From what I can tell, autoEnd is redundant and we don't actually use it at all. The only instance of it is here:

cypress/packages/driver/src/cy/commands/debugging.js

Lines 58 to 61 in e0c385e

	options._log = Cypress.log({
	snapshot: true,
	autoEnd: false,
	timeout: 0,

However, using autoEnd requires calling log.finish():

cypress/packages/driver/src/cypress/log.js

Lines 443 to 451 in e0c385e

	finish () {
	// end our command since our subject
	// has been resolved at this point
	// unless its already been 'ended'
	// or has been specifically told not to auto resolve
	if (this._shouldAutoEnd()) {
	return this.snapshot().end()
	}
	},

But I can't find any instances of calling log.finish() and the instance from above that uses autoEnd: true calls log.end(), which is the imperative way to end the snapshot, indicating it was never the intention to "auto-end" the log for cy.pause():

cypress/packages/driver/src/cy/commands/debugging.js

Lines 74 to 76 in e0c385e

	if (options.log) {
	options._log.end()
	}

The autoEnd option can probably be removed entirely, but that's outside the scope of this PR. I added the end option to the types since it's the one we actually use around the codebase for auto-ending a log. I guess this was the first time it was used in TypeScript though, so we hadn't noticed the omission before.

[flotwig]

the reason to not throw here is because the AUT could emit a postMessage to top, and we shouldn't fail the test in that case?

[chrisbreiding]

This is another bare-minimum implementation to get the ball rolling. We're planning more work on this in the future to put more thought into it and flesh it out more.