[FEATURE]: A function which only searches for displayed elements

[adrian-tankard-senetas]

Description

Given the website I work on has 4 duplicate elements for each field And only 1 of the 4 elements are displayed at any one time And none of the elements in the DOM contain any details that specify if the element is displayed When I search for the element using the L() function Then (I think) only the 1st element is returned which is not displayed NEW FEATURE: Then I can use a function which only returns displayed fields

Alternatives

Currently I have written an interaction which searches for the field And then I filter out the hidden fields So my interaction to fill in a field looks like this:

public class FillInField : ITask
{
    public string Phrase { get; }
    public string TextToSend { get; }

    private FillInField(string phrase, string textToSend)
    { Phrase = phrase; TextToSend = textToSend; }

    public static FillInField For(string phrase, string textToSend) =>
      new FillInField(phrase, textToSend);

    public void PerformAs(IActor actor)
    {
        var driver = actor.Using<BrowseTheWeb>().WebDriver;
        var fieldList = driver.FindElements(By.XPath(Phrase));
        var displayedField = fieldList.FirstOrDefault(c => c.Displayed == true);

        displayedField?.SendKeys(TextToSend);
    }
}

Anything else?

No response

Commitments

• [X] I agree to follow Boa Constrictor's Code of Conduct.
• [ ] I want to work on this issue myself. (This is voluntary, not required.)

[CoffeeAtBedtime]

🤔 @adrian-tankard-senetas are you able to share an example of the elements as they appear in the DOM? If they are there but some are visible on the page and others are not there has to be some sort of attribute, property or CSS that is affecting this. If so the Path could be updated to include this condition and bypass the need to do the filtering.

[adrian-tankard-senetas]

Hi Steve, Yes you can use this web page https://alpha.suredrop.dev/#/viewLogin For the user name field I am currently using this horrible xpath: @.="username"] I would like to use this xpath: @.="username"]

Once I have logged in there are other examples that I have to deal with. Like cancel buttons on dialogs.

Good luck Steve, Adrian.

On Mon, 5 Dec 2022 at 06:23, Steve @.***> wrote:

🤔 @adrian-tankard-senetas https://github.com/adrian-tankard-senetas are you able to share an example of the elements as they appear in the DOM? If they are there but some are visible on the page and others are not there has to be some sort of attribute, property or CSS that is affecting this. If so the Path could be updated to include this condition and bypass the need to do the filtering.

— Reply to this email directly, view it on GitHub https://github.com/q2ebanking/boa-constrictor/issues/213#issuecomment-1336496683, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN5S27RTBFBZB6QQY6A2FF3WLTVRRANCNFSM6AAAAAAQ5722YA . You are receiving this because you were mentioned.Message ID: @.***>

[CoffeeAtBedtime]

After looking at this I see 18 form inputs on your page in the Chrome console when I query. The difference between what is displayed and not displayed is the presence of a parent element with the css class "ng-hide". I would update your xpath to exclude any parent divs that may have ng-hide in them prior to an input element. This should do the filtering for you.

[adrian-tankard-senetas]

Thanks Steve, For the username field, could you please provide an example.

Cheers, Adrian.

On Mon, 5 Dec 2022 at 08:19, Steve @.***> wrote:

After looking at this I see 18 form inputs on your page in the Chrome console when I query. The difference between what is displayed and not displayed is the presence of a parent element with the css class "ng-hide". I would update your xpath to exclude any parent divs that may have ng-hide in them prior to an input element. This should do the filtering for you.

— Reply to this email directly, view it on GitHub https://github.com/q2ebanking/boa-constrictor/issues/213#issuecomment-1336519932, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN5S27VY66KDBFCYWL743KDWLUDHJANCNFSM6AAAAAAQ5722YA . You are receiving this because you were mentioned.Message ID: @.***>

[CoffeeAtBedtime]

You would be including early in your xpath a check for any parent div of these form input elements to not have the css class ng-hide. It will be something like /div[not(contains(@class, "ng-hide"))] watch this video for better understanding https://www.youtube.com/watch?v=dPluub64PIE experiment with your usage of absolute and relative in your xpath https://stackoverflow.com/questions/43100052/difference-between-and-in-xpath.

[AutomationPanda]

My gut reaction is to agree with @CoffeeAtBedtime. Filtering for visible elements can be done entirely within the locator's query.

However, I think there might be a deeper opportunity here for richer locators. Right now, the locator class essentially just holds the query. What if it could hold properties like shadow DOM roots and filters like being displayed? This might dovetail nicely with our plans to support shadow DOM in Boa Constrictor 3.