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.
jquery/jquery#2227
jquery/jquery#2604

Issues

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

Not reproducible issues

• Not reproducible Element is hidden by parent but should('not.be.visible') fails Element is hidden by parent but should('not.be.visible') fails #683
• Not reproducible Cypress doesn't handle visibility assertions for fixed or/and transform: translate Cypress doesn't handle visibility assertions for fixed or/and transform: translate #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 Improve UI when el not actionable by distinctly displaying stale elements vs hidden elements #696 (comment) (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.