perf: experimental "fast mode" for visibility checks

[cacieprins]

• Closes Experimental "Fast" Visibility #33044

Additional details

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 #68006

Run Properties:   Passed #68006  •  8fc92cb62a: Merge branch 'develop' into visibility-performance

Project	cypress
Branch Review	visibility-performance
Run status	Passed #68006
Run duration	19m 26s
Commit	8fc92cb62a: Merge branch 'develop' into visibility-performance
Committer	Cacie Prins
View all properties for this run ↗︎

---

Test results
Failures	0
Flaky	13
Pending	1098
Skipped	4
Passing	26965
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

[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

[cacieprins]

While it's good DRY practice, I think it makes sense to keep them separate for now, especially if we end up removing the classic visibility codepath. Splitting the algorithm across files will make it a little more difficult to follow.

[jennifer-shehane]

again specifies as e2e

[jennifer-shehane]

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