Change between 1.8.0 and 3.0.0 when using Wait Until Element Is Not Visible. In 3.0.0 element is consider visible if the element does not exist in the DOM.

[aaltat]

When I have this:

*** Settings ***
Library           Selenium2Library


*** Test Cases ***
Wait Untill Not Visible
    Open Browser    https://www.google.fi/    Chrome
    Wait Until Page Contains Element     id=lst-ib
    Wait Until Element Is Not Visible    id=foobarNotVisible
    [Teardown]    Close All Browsers

Then wen I run it with 1.8.0 release, then the test passes. But when I run the test with 3.0.0 release the test fails. More details in logs_with_differet_versions.zip. In the 1.8.0 the element is considered as not visible when the element does not exist in the DOM. But there is change in the 3.0.0 release and element is not considered as invisible if the element is not int he DOM.

It would be best consider element invisible also when the element is not in the DOM.

[pekkaklarck]

Could you clarify?

[pekkaklarck]

Read the discussion on the mailing list. Did I got it right that with earlier versions Wait Until Element Is Not Visible succeeded if element didn't exist at all, but nowadays it needs to exist and be invisible? If yes, I would say the old behavior makes more sense. From the end user perspective it doesn't really matter is an element invisible or not there at all.

Assuming I've understood this correctly, I would say we need 3.0.1 release with a fix soon but I don't think an immediate release is necessary. Better to wait at least few days to see are other similar issues encountered. The title and possibly also the description should also be updated to describe the problem a bit better.

[aaltat]

Yes, you are correct.

I also agree that it should not matter that is element in the DOM or not. If the element is not in the DOM, it is not visible and keyword should not fail.

Hello,

I can confirm we also do have issue with this method.
Here you can see logs with wait 1s and 60s

Logs.zip
We are talking about custom suite setup in the log files.
We have modified our code to found out the root cause.
We enhanced Wait until element is not visible with Run keyword and Continue on failure to see more.

In 1s timeout log file you can see test failed because "still visible after 1 second" = that means the element was present and its correct method failed.
In 60s timeout log file shows Element "element with locator not found." which is weird, because we know the element was there and disappeared - the keyword should pass.
We added Get Element Count before keyword and right after, to be sure, what is happening there.

Based on this investigation we do think the behavior in new selenium 3.0.0 is different.

[boakley]

I also agree that it should not matter that is element in the DOM or not. If the element is not in the DOM, it is not visible and keyword should not fail.

I disagree. To be consistent with other keywords, I think if the element is not present in the DOM then the keyword should throw an error.

Consider the case where you have a typo in the locator. Do you want the keyword to just silently pretend the locator is there and not visible? I think if you give it an invalid locator, it should tell you.

[boakley]

From the end user perspective it doesn't really matter is an element invisible or not there at all.

Perhaps that is true, but from the perspective of the test developer, that's a critical difference. If I have a typo in my locator, I don't want the keyword to silently accept the locator as valid. Think of the simple case of id=progres instead of id=progress. If we silently assume that no element == invisible element, the test might continue on even though a progress indicator is still visible.

[geist-scm]

I like the behavior that if not in DOM than not visible. I was using it this way as it made some logic simpler.

For example on the embedded systems I test on some are not very powerful; it can take up to 10 secs to generate keys for https negotiation. This can causes delays like this:

• I load a TLS cert to DUT to be used for https.
• The GUI will return success but the DUT is restarting its web server
• So the GUI often will not succeed in making a background polling API call to DUT during this.
• Which causes GUI to go modal with 'popup' of lost contact
• My test will fail since it cannot navigate away to start next test.

In this case my logic waits an empirically determined time than checks to see if lost contact pop-up is there. This logic started failing on the faster embedded h/w with SeleniumLibrary 3.0.0 because the pop-up never shows up.

I moved to kw 'Wait Until Page Does Not Contain Element' for fix but I am concerned this will fail when I start testing on the slower h/w Because of the way our SPA GUI works; If a popup is used and then removed thru click or change in state (polling succeeded) its html is left in the DOM but marked so it is not visible. The next time some event causes a complete page redrawn the old pop-up html is removed.

So if Wait...Not Visible fails when not in DOM I will have to change logic to:

• Check if ID in DOM, if so then wail till not visible.

Workable but not as simple.

-Paul.

[boakley]

So, you're not concerned about the case where you might accidentally give it an invalid locator?

…

On Mon, Dec 4, 2017 at 12:42 PM, Geist ***@***.***> wrote: I like the behavior that if not in DOM than not visible. I was using it this way as it made some logic simpler. For example on the embedded systems I test on some are not very powerful; it can take up to 10 secs to generate keys for https negotiation. This can causes delays like this: - I load a TLS cert to DUT to be used for https. - The GUI will return success but the DUT is restarting its web server - So the GUI often will not succeed in making a background polling API call to DUT during this. - Which causes GUI to go modal with 'popup' of lost contact - My test will fail since it cannot navigate away to start next test. In this case my logic waits an empirically determined time than checks to see if lost contact pop-up is there. This logic started failing on the faster embedded h/w with SeleniumLibrary 3.0.0 because the pop-up never shows up. I moved to kw 'Wait Until Page Does Not Contain Element' for fix but I am concerned this will fail when I start testing on the slower h/w Because of the way our SPA GUI works; If a popup is used and then removed thru click or change in state (polling succeeded) its html is left in the DOM but marked so it is not visible. The next time some event causes a complete page redrawn the old pop-up html is removed. So if Wait...Not Visible fails when not in DOM I will have to change logic to: - Check if ID in DOM, if so then wail till not visible. Workable but not as simple. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1008 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABEmYrdFEVfwh6CehORxFShL1oHG-jfEks5s9D0vgaJpZM4Q0S5x> .

[geist-scm]

No. That reflects a bug in the code and I am not one that thinks the language should try to protect one against such things. (just my opinion, old UNIX guy ;-) )

In my case if I used the wrong locator and the Wait passed when it should not another error would happen since the element would still be there. In my case most are pop-ups that are modal.

[aaltat]

To check that something is not there is generally a difficult problem. I understand both views and can think use cases for both implementations. Perhaps it would be best to make it configurable, should the keyword fail, if the element is not in the DOM.

[geist-scm]

I had also thought about making it configurable but hesitated to suggest something that is more work. I like this idea.

[pekkaklarck]

I'm in general fine with either behavior, but for backwards compatibility reasons think we should restore the old behavior. Most importantly the behavior needs to be documented.

I'm not really against configuration, but don't think it's
worth the effort. If the old behavior is the default, possible typos in locators aren't detected anyway. If you really want to test element exists but is invisible (are there use cases for this?) it's easy by using this kw in combination with Page Should Contain Element or similar. Again, documentation is the key.