Cypress: Element visibility fixes

[jennifer-shehane]

There are multiple issues regarding elements being calculated as visible when they are hidden OR elements being calculated as hidden when they are visible. This issue is generally to be used to track the progress made for these fixes.

I think that it is interesting to note that jQuery ditched their visibility calculations in 3.0 and is likely worthwhile looking into why/how they made these decisions.

An element is considered now visible if it has a layout box returned from the DOM getClientRects() method, even if that box has a height and/or width of zero. This means that elements such as
or an empty element that don't have height are considered to be visible.
https://github.com/jquery/jquery/issues/2227
https://github.com/jquery/jquery/issues/2604

Issues

• [ ] Print reasons why Cypress considers an element 'visible' in errors.
  https://github.com/cypress-io/cypress/issues/677
• [ ] Opacity is not considered for visibility checks https://github.com/cypress-io/cypress/issues/4474
• [x] Elements hidden using clip / clip-path css properties pass as visible
  https://github.com/cypress-io/cypress/issues/1178
• [x] position: fixed elements having parent with pointer-events: none mistakenly display as not visible / covered by another el https://github.com/cypress-io/cypress/issues/6675
• [x] Inline, zero-dimension element: erroneous visibility determination https://github.com/cypress-io/cypress/issues/6183
• [x] Can't click on some rotated buttons https://github.com/cypress-io/cypress/issues/2921
• [x] Inability to determine why element isn't visible #5974
• [x] Cypress fails when use should('be.visible') on a visible element - overflow hidden with position absolute outside https://github.com/cypress-io/cypress/issues/4395
• [x] 'visible' assertion says visible for elements cropped by parent element with overflow: hidden https://github.com/cypress-io/cypress/issues/4161
• [x] When 'is.visible' failure, error shows 'is being covered by another element: undefined' https://github.com/cypress-io/cypress/issues/1379
• [x] .should("be.visible") doesn't interpret elements with " style='transform: scale(0,0)' " correctly https://github.com/cypress-io/cypress/issues/723
• [x] backface-visibility: hidden doesn't hide elements from cypress https://github.com/cypress-io/cypress/issues/2985
• [x] on .type() says failed element is not visible, but el is visible https://github.com/cypress-io/cypress/issues/1818
• [x] backface-visibility: hidden with transform-style: preserve-3d fails the "is.visible" test https://github.com/cypress-io/cypress/issues/5682
• [x] should('not.be.visible') fails for non visible elements dur to overflow: hidden and set height https://github.com/cypress-io/cypress/issues/5959

Not reproducible issues

• Not reproducible Element is hidden by parent but should('not.be.visible') fails https://github.com/cypress-io/cypress/issues/683
• Not reproducible Cypress doesn't handle visibility assertions for fixed or/and transform: translate https://github.com/cypress-io/cypress/issues/2558

Desired behavior:

• Find a better way to more accurately determine visibility.
• Always display reason why we determine something as visible or not visible.
• Add tests for all failing cases above - get tests passing

Versions

Cypress: 3.3.1

┆Issue is synchronized with this Jira Bug by Unito

[jennifer-shehane]

I've made a flowchart of our current implementation for visibility checks. This applies when using cy.get('el').should('be.visible'), etc as well as some other checks we do before actions are taken: .check(), .click(), .type() and some instances of .trigger()

Some notes upon review of the diagram on changes we want to make:

• What would be great is to not only have the flowcharts for use in the docs, but to also have examples of each one so that people understand the rules and situations in which its visible.
• In Command Log where eyeball displays - need to refactor this logic as per https://github.com/cypress-io/cypress/issues/696#issue-261674444 (not in scope of this current issue)

Separate out the "loose" checks from "strict" checks for visibility. Today is all "loose" checks -- "strict" checks concerns whether the element is visible within the viewport and the necessity to scroll to an element first.

"Loose" visibility checks

• Should prove the element is hidden, fall through to visible if not.
• Checks tiny heuristics of element - is visibility: collapse, is within css-path, etc., etc. etc.
• Used for 'is.visible' assertions. Meant to represent if the element can be seen by a person without disabilities and 20/20 vision.

"Strict" visibility checks

• Should prove the element is visible, fall through to hidden if not.
• Checks just clientRect + elFromPoint and edge cases.
• Used for actionability checks - some things are not really visible to the eye, but the mouse will click it if the user is on the coordinates and clicks, for example.

Questions

• Do we introduce a new assertion? pseudo-selector? flag?
• Is there a better naming convention for loose vs strict??
• Screenshots + flowcharts for docs to describe "loose" versus "strict".

[jennifer-shehane]

I'm going to close this issue for tracking - as there are only a couple of remaining issues that should be resolved when opacity: 0 is considered, which there is a PR for.