-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inability to determine reason for invisibility #5974
Comments
I agree, this is pretty awful. I wrote this code as a catchall if a specific error message was not written for a hidden check. #4421 This is complicated by the fact that the Giving a repro would actually be really helpful because there must be a case we are checking but not printing a message for.
|
I figured out why. One of the ancestors has a CSS property * I know this is a completely non-sensical attribute for someone to give to an element. This is done by Google Maps. |
@badeball K, thanks for looking into this. I'll have to try to set up a test for this situation.
Recommended Action: |
Got a repro and also verified this is a regression introduced in 3.8.0, likely from this PR #5590. So this is actually incorrectly failing the visibility check also.
<!DOCTYPE html>
<html>
<body>
<div style="transform: translate(0, 0); height: 0;">
<p>Aenean lacinia bibendum nulla sed consectetur.</p>
</div>
</body>
</html>
it('types', function () {
cy.visit('index.html')
cy.get('p').should('be.visible')
}) 3.7.03.8.0 |
@jennifer-shehane Ill check it out. |
This is undoubtedly a very interesting case, along with the whole problem of programmatically determining visibility. You obviously made a great deal of effort here, which I am wholeheartedly appreciative of. However, I'd like to emphasize that what I originally wanted to address was the disconnect between reasoning and actual determination. As long as the two methods This message is non-sensical at the very core. Cypress does determine visibility and I believe it should always be able to tell you why in case it determined something to be invisible. |
Here's an example of what I mean by sharing heuristic, without changing the current interface. function determineVisibility ($el) {
if ( /* some condition */ ) {
return {
visible: false,
reason: "foobar"
};
}
return {
visible: true
};
}
export function isHidden ($el) {
return !determineVisibility($el).visible;
}
export function getReasonIsHidden ($el) {
const visibility = determineVisibility($el);
if (visibility.visible) {
throw new Error("Erroneously invoked on a visible element");
}
return visibility.reason;
} |
@sainthkh I also ran this, without a parent, where the <!DOCTYPE html>
<html>
<body>
<p style="transform: translate(0, 0); height: 0;">
Aenean lacinia bibendum nulla sed consectetur.
</p>
</body>
</html> |
As you can see in the screenshot, "without-a-parent" problem is not the problem of the #6000. It's the problem of effective width or height. It's not regression. It's been fixed by checking the value of effective width/height and transform value together. |
@sainthkh it looks like the PRs you mentioned are merged now. Is this issue fixed, or is there still more work to do? We're blocked on upgrading Cypress to >= 3.8 due to this issue. Thanks! |
@janakdr I've been spending time on #5762. And my part is finished and I'm waiting for feedback. If your problem is the test falsely failing, then it is solved in #6000. Please try 3.8.2. But your idea about creating a visibility result object to determine the reason is not started yet. Currently, I'm trying to make #619 and planning to fix that with #677. |
Thanks, the failing test was our issue, and 3.8.2 does fix it!
…On Tue, Jan 14, 2020, 7:13 PM Kukhyeon Heo ***@***.***> wrote:
@janakdr <https://github.com/janakdr> I've been spending time on #5762
<#5762>. And it is finished my
part and waiting for feedback.
If your problem is the test falsely failing, then it is solved in #6000
<#6000>. Please try 3.8.2.
But your idea about creating a visibility result object to determine the
reason, it is not started yet.
Currently, I'm trying to make #619
<#619> and planning to fix
that with #677 <#677>.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#5974?email_source=notifications&email_token=ACNKK4CAUFPL7EZLRFO6J23Q5ZILLA5CNFSM4J3NE6UKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEI6S6CY#issuecomment-574435083>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACNKK4GOCG4AWASBGFBSPCDQ5ZILLANCNFSM4J3NE6UA>
.
|
This was fixed in #6000 in 3.8.2 of Cypress. Closing as resolved. |
I hate to be the stickler here, but this issue was equally much about the fact that the reason for determining invisibility was unavailable. As far as I can see, there's still two different methods of determining invisibility and for explaining why an element is invisible. This means that this can still become an issue again and therefore it will. |
Yah, there's a larger issue to evaluate our error messages - showing why something is invisible or visible here: #677 As far as I have seen, there aren't any open issues of a situation where the ambiguous error 'could not determine why' is showing for anyone in the current version. |
Current behavior:
Per v3.8.0, one might receive a message stating EG.
Cypress could not determine why this element '<button>' is not visible.
This is non-sensical, as there's obviously some heuristic implemented that has determined the element to be invisible.
I understand that there's a method
getReasonIsHidden
that is somewhat replicating the behavior ofisHidden
, but returning a human-readable string instead of a boolean value. I am however having a very hard time understanding why you would implement it like this.Since there should be one, and only one, heuristic-implemention, why not make one a function of the other?
Desired behavior:
Never to see such a non-informative error message.
Steps to reproduce: (app code and test code)
Doesn't really matter here, but I can see if I can produce a minimal example.
Versions
Cypress v3.8.0, Arch Linux, Chrome 77.
The text was updated successfully, but these errors were encountered: