As the guide documented:
The scrolling algorithm works by scrolling the top, leftmost point of the element we issued the command on to the top, leftmost scrollable point of its scrollable container.
This cause some element cannot be clicked and the "nudge" seems not working.
I've produced a smallest example for the bug on codepen:
https://codepen.io/yuyz0112/pen/jpeZvZ
Cypress code:
cy.contains('3').click();
After execute click command, the item contains '3' scrolled to the top and was covered by the mask element.
I'm not sure whether this situation should be covered by the scrolling strategy, but I still expect a method to test this without change my code.
v3.0.3
I think this is related to #871 , is there any updates on that issue?
https://github.com/cypress-io/cypress/blob/develop/packages/driver/src/cy/actionability.coffee#L230
Looks like I can disable the verify process by adding { force: true }
?
If I'm right I can close this issue.
Yes, you can disable our checks on whether the element is 'clickable' by just passing { force: true}
, but ideally the click here should work without you having to do that.
@jennifer-shehane
Ok, so I'm going to keep this issue open.
But what you mean is that Cypress will not scroll automatically since the target element will be covered by another(The mask element is not the ancestor of target element), or Cypress will scroll but can still click when target element was covered?
Cypress is supposed to automatically scroll the element into view - but due to Element#scrollIntoView
it is technically possible the browser scrolls the element in a way that is impossible for the user to have done, and it can create situations in which the DOM is completely locked and it is incapable of "scrolling" to get it into view.
This looks like one of these situations. We've internally decided that our algorithms should always scroll (to be deterministic) but we've been reconsidering this since scrolling is a mutation and there have been side effects that cause problems like these.
And/or in addition to, we've been considering just allowing you to pass a { scroll: false }
or even change the scrolling strategy to be that of "if-necessary", "middle", "bottom", etc.
@brian-mann
Yeah, I think cover all the case of scroll into view is really hard, an configurable scrolling strategy may solve most of the problems.
But now { force: true }
already help me in this situation, so maybe we can close this issue and keep tracking the configurable strategy implementation in #871?
I'm having the same issue. The problem is that the "changeable scrolling strategy" feature (#871) was discussed about a year ago and nothing has happened so far.
Please don't close this.
This should be fixed when we change our default scroll strategy to center the element in the viewport, part of ~4.0~ 5.0
Also having problems with overscrolling elements. Check the video please: https://github.com/cypress-io/cypress/issues/871#issuecomment-509392310
spec.js
it('can click the 3 behind masked el', () => {
cy.visit('index.html')
cy.contains('3').click()
})
index.html
<html>
<style>
.item {
padding: 15px;
background: lightsteelblue;
}
</style>
<body>
<div class="container" style="width: 400px;">
<div class="mask" style="padding: 15px; background: lightpink; z-index: 2; position: relative;">mask</div>
<div class="long-list" style=" height: 300px; overflow: auto; margin-top: -48px;">
<div class="item">placeholder</div>
<div class="item">1</div>
<div class="item">2</div>
<div class="item">3</div>
<div class="item">4</div>
<div class="item">5</div>
<div class="item">6</div>
<div class="item">7</div>
<div class="item">8</div>
<div class="item">9</div>
<div class="item">10</div>
</div>
</div>
</body>
</html>
it seems like the problem is that cypress call "scrollIntoView" which hides the element when the element has a parent element with scroll.
if that's the case then:
element.scrollIntoView({block: "end"});
should fix that.
closing this as a duplicate of #871, which has an associated PR open
Most helpful comment
I'm having the same issue. The problem is that the "changeable scrolling strategy" feature (#871) was discussed about a year ago and nothing has happened so far.
Please don't close this.