position: fixed elements having parent with pointer-events: none mistakenly display as not visible / covered by another el
#6675
Comments
|
This seems to be due to the parent element of the I'm not seeing this ever really working correctly. Tried in 3.3.0, 3.4.0, 3.5.0, 4.1.0. Reproducible Example:
<html>
<body>
<div style="pointer-events: none;">
<div class="spinner" style="position: fixed;">↺<div/>
</div>
</body>
</html>
it('pointer events on fixed element', () => {
cy.visit('index.html')
cy.get('.spinner').should('be.visible')
})WhySeems to be a note from brian a long time ago regarding this #1887 (comment):
From https://developer.mozilla.org/en-US/docs/Web/API/DocumentOrShadowRoot/elementFromPoint
Code that needs fixingThis function is called to determine if a fixed element is being covered by another element, which is essentially calling |
jennifer-shehane
changed the title
position: fixed elements having parent with pointer-events: none mistakenly display as not visible / covered by another el
jennifer-shehane
added
type: bug
topic: visibility 👁
pkg/driver
cypress-bot
bot
added
the
stage: ready for work
|
Thank you for looking into this further @jennifer-shehane! |
|
I've come across a variation on the same problem. In my case it's a tooltip on a modal/overlay, which means the nesting is inverted ( index.html <!DOCTYPE html>
<html>
<head></head>
<body>
<div style="position: fixed;">
<div id="tooltip" style="pointer-events: none; border: 2px solid maroon;">Tooltip</div>
</div>
</body>
</html>spec.js it('pointer events within fixed element', () => {
cy.visit('index.html');
cy.get('#tooltip').should('be.visible');
});One solution that comes to mind is that if the tested element (or any parent) has
Is this kind of thing realistic? I'm not at all familiar with the Cypress internals. One drawback is that we don't know if there are other obscuring elements with Also out of curiosity, why does this only happen when there is a parent with |
|
@samjetski The majority of the visibility code can be found here: https://github.com/cypress-io/cypress/blob/develop/packages/driver/src/dom/visibility.js#L20:L20 Doing something like noted is not uncalled for for how we check visibility of elements. It's very specific checks. |
|
I'm wondering why there's no There's also no mention of z-index or stacking in the source for visibility which I find suspicious. |
|
This is still reproducible in Cypress 4.9.0 |
cypress-bot
bot
added
stage: work in progress
stage: needs review
cypress-bot
bot
added
stage: pending release
and removed
stage: needs review
|
The code for this is done in cypress-io/cypress#8095, but has yet to be released. |
|
Released in This comment thread has been locked. If you are still experiencing this issue after upgrading to |
Current behavior:
Hi,
Currently, when testing out the visibility of
.spinnerfor nprogress, it shows as being not visible due to the position being fixed although the spinning circle loader is certainly visible on the page. I'm aware of the complexity of the current algorithm used to determine visibility so I thought this might help give a simple, reproducible example of where this may (if I'm understanding correctly) fail. It says that it's being covered by the html wrapper itself, but the element has a z-index set to 1031.Desired behavior:
It should be considered visible as it's not being covered by any element in the DOM.
Test code to reproduce
https://github.com/josh-byster/cypress-visibility
There is a
visibility.spec.jswhich has a basic assertion of visibility in there that should show the issue.If there's any trouble with reproducibility, it can probably be tested directly at the nprogress website to check if the spinner is visible.
Versions
Cypress 4.1.0
Mac OS X Catalina 10.15.3
The text was updated successfully, but these errors were encountered: