perf: experimental "fast mode" for visibility checks

[cacieprins]

• Closes Experimental "Fast" Visibility #33044

Additional details

This is a DRAFT proposal

In order to verify performance improvements, this adds a "stress test" e2e test to the driver that simulates interacting with extremely large virtual scrolling lists. This test should probably not be run with "legacy" visibility, as it immediately causes the browser to eat up all available memory and crash. This fixture works perfectly fine outside of Cypress.

This introduces an experimentalFastVisibility option, that switches our visibility detections to an alternative algorithm. This algorithm has some caveats, but it is much faster than the current visibility algorithm.

Cypress uses this visibility algorithm not just for visibility assertions, but also for every interaction that requires "interactability." It's memory intensive and can cause unnecessary layout thrashing due to repeated access of CSS properties that require layout recaulcation.

The "fast" visibility algorithm:

1. Assumes body and html are always visible; this is in line with current visibility behavior
2. Uses the built-in checkVisibility method as first pass, with all options enabled. The following states are considered hidden by this method:

• The element does not have an associated box
• The element is not being rendered because it or one of its ancestors has set content-visibility to `hidden
• It has an opacity of 0
• The value of its visibility property makes it invisible
• content-visibility CSS value is auto, and its derived value prevents the element from being rendered

3. If the element is an <option> or <optgroup>, it defers to the visibility of the parent <select> element. If there is no parent <select> element (an invalid DOM tree state), the element is considered hidden.
4. If the element is still considered visible, it performs a more comprehensive check with an adaptive point sampling algorithm

The point sampling algorithm:

1. Implements a visibleAtPoint check, which uses document.elementFromPoint to determine which element is at the top of the render context at that point. If the element at that point is the subject element or a child of the subject element, the subject element is considered visible at that point.
2. From the bounding rectangle of the subject element, it checks the four corners and center. If any of these points are visible, the subject element is considered visible.
3. If none of these points are visible, it divides the bounding rectangle in to four sub-rectangles, and performs the same sampling on them.
4. The sampling algorithm returns true if any part of the element is visible, but for performance constraints it will only subdivide to a limited depth, and will stop subdividing if the sampling rectangles fall below 1px in both dimensions.

Benefits over the legacy algorithm:

• Constant-time in the best case, and bounded exponential in the worst case (point sampling on a fully hidden element)
• Detects when an element is fully covered by positioned elements outside its ancestor tree
• Can be tweaked to provide access to threshold-based visibility
• Could be extended to require a minimum visible size for an element to be considered actionable tap events, to test conformation with UX guidelines regarding the size of touch targets
• Does not crash when running the virtual scroll stress tests

Caveats:

• Elements that are outside the bounds of the browser viewport will always be considered hidden with this algorithm
• Elements with pointer-events:none either explicit or inherited will always be considered hidden
• <option> elements that are not a direct child of <select> or <optgroup> elements are not considered visible
• <optgroup> elements that are not a direct child of <select> or <optgroup> elements are not considered visible
• Certain other edge cases that are considered hidden to this algorithm may be visible to the user, especially when it comes to elements that have a 0 height or width and have visible children. In these cases, it may be better to assert visibility on the visible children rather than the containing element.
• Shadow dom support is unknown at this time
• Some of the current visibility.cy.ts tests fail because the subject element is either off-screen, or covered by an absolute/fixed element that is not an ancestor.
• If even 1px of the subject element is visible, it will be considered visible. Potential consideration: configurable threshold?

Future performance improvements:

• Memoize elementFromPoint calls
• delete old records from memoization maps to reduce memory footprint
• Use requestAnimationFrame to measure the BoundingClientRect of the subject element; this is difficult due to how the visibility & interactability checks are currently wired through jquery selectors, which prevents this method from being async

Steps to test

How has the user experience changed?

PR Tasks

• Have tests been added/updated?
• Has a PR for user-facing changes been opened in cypress-documentation? Experimental fast visibility cypress-documentation#6337
• Have API changes been updated in the type definitions?

[cypress]

cypress    Run #67921

Run Properties:   Failed #67921  •  578f3d58a6: changelog

Project	cypress
Branch Review	visibility-performance
Run status	Failed #67921
Run duration	46m 29s
Commit	578f3d58a6: changelog
Committer	Cacie Prins
View all properties for this run ↗︎

---

Test results
Failures	2
Flaky	12
Pending	1098
Skipped	4
Passing	26834
View all changes introduced in this branch ↗︎

---

Warning

Partial Report: The results for the Application Quality reports may be incomplete.

UI Coverage  45.48%
Untested elements	188
Tested elements	161

Accessibility  98%
Failed rules	4 critical   8 serious   2 moderate   2 minor
Failed elements	101

---

Tests for review

  settings.cy.ts • 1 failed test • app-e2e

View Output

Test		Artifacts
App: Settings > Project settings > shows the Experiments section		Test Replay Screenshots

  studio/studio-new-tests.cy.ts • 1 failed test • app-e2e

View Output

Test		Artifacts
Cypress Studio - New Test Creation > prompt for a new url > ensures we clear the aut url input properly in between adding and clearing urls		Test Replay Screenshots

  issues/28527.cy.ts • 1 flaky test • 5x-driver-electron

View Output

Test		Artifacts
issue 28527 > fails and then retries and verifies about:blank is not displayed		Test Replay Screenshots

  commands/location.cy.js • 1 flaky test • 5x-driver-chrome:beta

View Output

Test		Artifacts
... > does not log an additional log on failure		Test Replay

  e2e/origin/config_env.cy.ts • 1 flaky test • 5x-driver-chrome:beta

View Output

Test		Artifacts
cy.origin- Cypress.config() > serializable > overwrites different values in secondary if one exists in the primary		Test Replay

  issues/28527.cy.ts • 1 flaky test • 5x-driver-chrome:beta

View Output

Test		Artifacts
issue 28527 > fails and then retries and verifies about:blank is not displayed		Test Replay Screenshots

  e2e/origin/config_env.cy.ts • 1 flaky test • 5x-driver-inject-document-domain-chrome:beta

View Output

Test		Artifacts
cy.origin- Cypress.config() > serializable > overwrites different values in secondary if one exists in the primary		Test Replay

The first 5 flaky specs are shown, see all 12 specs in Cypress Cloud.

[jennifer-shehane]

There used to be some guidance on this, that I cannot find atm. But we put Performance at the top, above Features (since they usually impact generally everyone).

[jennifer-shehane]

@cacieprins Some notes to possibly address

[jennifer-shehane]

Seems this could be moved out of both functions and ad the top of the isHidden definition. Not a big deal though

[jennifer-shehane]

What was the decision here. Comment makes it sound undecided

[jennifer-shehane]

Can remove this note

[jennifer-shehane]

I might mention here that one would get benefit even if they are not explicitly doing a lot of 'visible' assertions.

[jennifer-shehane]

Is this only available in e2e? I think it's a global setting right?

[jennifer-shehane]

Suggested change

	npm run test
	npm run cypress run

[jennifer-shehane]

I might mention: correct behavior = visually look at it and see if it is visible or not!

[jennifer-shehane]

What is the result of passing shadow dom in? Will it give false results of visible or hidden? Can we not error in some way so people don't do this? (Determining if something is shadow dom is not exactly the most performant either probably, so I suspect not)

[jennifer-shehane]

again specifies as e2e

[jennifer-shehane]

I would have expected the force: true option to be mentioned in here at some point. I don't like it's use myself, but a lot of people lean back on using it.

[jennifer-shehane]

Need to add the descriptions for the App UI in Settings.