Cypress: Print reasons why Cypress considers an element 'visible' in errors.

[jennifer-shehane]

Is this a Feature or Bug?

Feature

Current behavior:

When I assert that an element .should('not.be.visible'), but Cypress finds that it is visible, it doesn't tell me why it considered the element visible.

Error: why does Cypress think it's visible??

Desired behavior:

Cypress should explicitly print the reasons for why Cypress considers an element 'visible' when it fails .should('not.be.visible') assertion (just as it does for when it fails .should('be.visible')).

My specific use case had to do with an element on my page having a style of {opacity: 0}. So, to me, the element seems to not be visible and I expected a .should('not.be.visible') assertion to pass.

After speaking with the Cypress team, the current behavior is correct however. Since the browser actually allows users to interact with elements that have {opacity:0} and Cypress uses this visibility algorithm to determine if elements are intractable, they do not intend to change this behavior.

The list of reasons for why Cypress considers something visible may have a specific message about opacity listed first?

How to reproduce:

cy.get('.el-with-opacity-zero').should('not.be.visible')

Reasons why an element is considered visible

Reasons why an element is considered not visible

• The element is partially covered by another element, so not _fully_ visible as in https://github.com/cypress-io/cypress/issues/3369
• The element has been detached from the DOM (is effective height/width of 0) https://github.com/cypress-io/cypress/issues/696#issue-261674444

┆Issue is synchronized with this Jira Features by Unito

[crcatala]

Just ran into this issue. I agree that logging a specific reason (opacity) allows the user some context to why the the assertion failed. If such logging isn't a priority, perhaps even a mention in documentation about this caveat could be useful?

[L0wry]

This will probably be a deciding factor if we use cypress as our go-to ui testing tool very very soon.

plz help

[enjikaka]

Also ran into this now. For performance we show/hide elements with opacity rather thandisplay. Cypress considers an element hidden with opacity: 0 to be visible, failing our test when doing .should('not.be.visible').

I'd consider that a bug.

[tnrich]

Also running into this right now. I agree opacity 0 element should not be considered visible/clickable. Definitely a bug IMO.

Is there a way to work around this? Like by adding some sort of :not(opacity=0) to the selector?

Thanks!

[tnrich]

Hmm I did find this article which makes the point that elements with opacity 0 do still take up space on the page so considering them not visible might not quite be correct.. https://davidwalsh.name/offsetheight-visibility

[dudewad]

@tnrich does that mean that visibility: hidden is also "not quite" hidden?
I can see that there is some distinction to be made between the fact that it pushes other things around yet is transparent. What visible means should at the very least be clarified in an easier-to-find place in the documentation -- I can't for the life of me actually figure out what visible means.

[qodesmith]

I have display: none on an element and Cypress still fails when I assert .should('not.be.visible') :(

[jennifer-shehane]

@qodesmith Please open an issue with a complete reproducible example of this so we can fix it.

[qodesmith]

@jennifer-shehane I'm so sorry, I take it back. My element had opacity: 0 not display: none.

[sainthkh]

It seems that we can use the idea in #5974. But it needs heavy refactoring. So, it'll create a lot of conflicts unless #5916 and #6000 are merged.