When opacity === 0, the element should be considered as not visible to avoid evaluating the next command sooner than expected and causing flakiness.
I think the issue is pretty clear from the image, but I can provide reproduction later if you consider it necessary.
[email protected]
Electron 61
Windows 10 x64
Nice. Thanks for opening this issue. Was going to do this myself.
I am currently working on visibility fixes - one of which was implementing this change for opacity. We had initially decided not to consider elements with opacity 0 as 'not visible', because they are still interact-able, but we're going to be pulling this all out into a broader issue so that there can be different checks for 'can be seen', 'can be seen in viewpor', and 'can be interacted with'
Read more here: https://github.com/cypress-io/cypress/issues/1242
Some of our previous reasoning: https://github.com/cypress-io/cypress/issues/677
I actually have already written the code for the opacity check (commented out in this PR https://github.com/cypress-io/cypress/pull/4421) - as this would be implemented as part of the 'can be seen' code, but I think due to the change, this would have to go into a major code version update as it would be breaking our users current expectations.
Make sure that 0
is a string in your assertion, not a number - as all css properties evaluate to strings.
cy.get('div').should('have.css', 'opacity', '0')
We had initially decided not to consider elements with opacity 0 as 'not visible', because they are still interact-able
I have actually worked on a piece of code that also set the pointer-events
to none
; effectively making it non-interactable. This was done to have an invisible element fade in using CSS transitions. (display: none will kill the fade)
@jennifer-shehane I think that the fact that opacity: 0
is considered visible due to the interactivity, is a fairly good argument, as long as two things are taken into account:
timeout
, we could have opacity-is-visible
(bad name, but good for the example).What do you think?
The code for this is done in cypress-io/cypress#8244, but has yet to be released.
We'll update this issue and reference the changelog when it's released.
This fix requires a breaking change, so is targeted for our next breaking change release. You can follow along with progress on this release here: https://github.com/cypress-io/cypress/pull/8437
Released in 6.0.0
.
This comment thread has been locked. If you are still experiencing this issue after upgrading to
Cypress v6.0.0, please open a new issue.
Most helpful comment
Nice. Thanks for opening this issue. Was going to do this myself.
I am currently working on visibility fixes - one of which was implementing this change for opacity. We had initially decided not to consider elements with opacity 0 as 'not visible', because they are still interact-able, but we're going to be pulling this all out into a broader issue so that there can be different checks for 'can be seen', 'can be seen in viewpor', and 'can be interacted with'
Read more here: https://github.com/cypress-io/cypress/issues/1242
Some of our previous reasoning: https://github.com/cypress-io/cypress/issues/677
I actually have already written the code for the opacity check (commented out in this PR https://github.com/cypress-io/cypress/pull/4421) - as this would be implemented as part of the 'can be seen' code, but I think due to the change, this would have to go into a major code version update as it would be breaking our users current expectations.
Workaround Today
Make sure that
0
is a string in your assertion, not a number - as all css properties evaluate to strings.