I can access it in the console of the browser via document.querySelector("[data-testid=autoBrightnessToggleButton] [type=checkbox]").click();
But in Robot with Selenium Library I get an error message when I try this: Wait Until Element Is Visible css:[data-testid=autoBrightnessToggleButton] [type=checkbox]
Element ‘css:[data-testid=autoBrightnessToggleButton] [type=checkbox]’ not visible after 10 seconds.
I open the browser with the frame directly, so that there can not be an error with Selecting the wrong Frame.
The data-testid in your example is on the label element, not on the checkbox. So it’s looking for an element with data-testid=autoBrightnessToggleButton and which also is of the type checkbox.
I think you can make the example work by changing the selector to:
css:[data-testid=autoBrightnessToggleButton] > span > input[type=checkbox]
Maybe it could be written better, I mostly use xpath locators instead of css.
With the space there between the two css attribute selectors that looks fine to me. That is saying find an element starting with this data-testid attribute and then a descendent with type of checkbox. So essentially that is like the cascading locator strategy the library provides shown in your example Wilrik.
I’m a little unfamiliar with the current behavior of JavaScript click function but as I understand/recall it essentially is sending a click event directly to the element which may or may not be visible. So getting false when asking if it is visible after ten seconds and at the same time clickable if sending a JavaScript click event to it seems possible to me. Is this toggle button on the screen when viewed “manually” given any reasonable screen size or target screen size? If so you might check/set the window size for your automation. If it is not expected to be visible on screen then this experienced result makes sense.
[This then leads us into further discussion about clicking, scrolling, and maybe some more about visibility, etc … but want to see if I am on the right track or if something else is going on here …]
This is a part of the “website” under test. I marked the Toggle Button in red. The button is displayed at the top. So there should be no scrolling necessary. I use “Maximize Browser Window” after loading the page / frame.
I tried a lot, like copying the Xpath and CSS-locator out of the browser, etc. Nothing helped.
Is “>” not a separator of Xpath, but " " (space) the separator of css, Wilrik? I am unsure by myself now…
We use React to create the page, this is why I at first wait for the element to be displayed.
In the example above, I think what was being demonstrated was a special feature of the SeleniumLibrary and BrowserLibary. That is a method in text form to chain locators to be even more flexible in describing the element(s) one wants to interact with. That is it allow you to specify a “parent” locator using any of the specified strategies (css, xpath, id, etc) and then from that element find a child element using another or same strategy. It is described under the “Locating elements | Chaining locators” section in the SeleniumLibrary documentation. Actually I need to correct myself as that should be two less then symbols not a single one; so something like,
As noted though your css locator is fine. The error message you received is in part telling and reinforcing this in that it says the element which you are specifying is not visible, not that it could not find the element.
Ok, so it seems reasonable that the element is visible. Another good tip is to check the screenshots that SeleniumLibrary takes on an error within one of it’s keywords. So the Wait until element is visible should be taking a screenshot when it fails. (Don’t recall off the top of my head if it does every time it checks during the timeout. I think this one was written that it does not. But there should be one at least at the end with the failing library keyword.)
The screenshot, I would suspect, also reveals things like screen size. So if for example you are configured to run on a mobile device and it displays differently on a laptop I would expect the screenshot to show the mobile viewport. Here I say “suspect” and “expect” as I don’t know this 100% and not being able to “look over your shoulder” and see what you are seeing I am hesitant to say this is 100% the case for you … more of debugging techniques that need to be applied in your context …
I don’t know css as well as I know xpath myself so I miss some of that syntax as well. I tend towards referring back to this learning game - CSS Diner. And for checking css or xpath locators I use the DevTools Console solutions outlined in the “From Console panel” section here. Noting with much caution that I never use the “From Elements panel” method in that link as it has some flaws and make it not 100% accurate.
But one of my main points I share is that the error selenium gives is really indicative of the problem. So element not found is what I expect for either bad locators or timing issues.
Thank you, that works so far with the connected locators - I do now only wait for the testid to be visible, not for the checkbox.
Wait Until Element Is Visible css:[data-testid=autoBrightnessToggleButton]
Select Checkbox css:[data-testid=autoBrightnessToggleButton] >> xpath://input[@type=‘checkbox’]
But what does not work is that the Checkbox/Slider is being moved to its inactive position. So the report says Pass, but the slider remains in its position. Even pressing the checkbox twice (I know it ought to make no sense, but its a slider and not a “real” checkbox), lets it remain active:
Philipp, do you have some screenshots which show when manually toggled what the states you expect these two widgets should be in? (or just the one. it sounded like the toggle was connected to the slider in some fashion)
If it works manually then the general expectation I have is that automation should work as well.
Thinking about this and all that has been shared I would suggest try clicking the label element. That is
Click Element css:[data-testid=autoBrightnessToggleButton]
Another topic I cover when training others on SeleniumLibrary and web testing is understanding the DOM, order and strucutre of element groups and clicking the right element. As a user it generally is obvious where to click. But when seen as the DOM sometimes it is not as simple. I think this may be the case here. There are a few reasons why I say this in this particular case including the results of your waiting and that the label is a parent not a sibling of the input toggle.
That error, element not interactable, would be in line with all the other observations made. From the selenium api this error is given “… when an element is present in the DOM but interactions with that element will hit another element due to paint order.” This might also explain why in this instance it was never “visible”.
I’ll add I am not sure how universal this “issue” is within your specific app. I wouldn’t tend to write all locators and interactions as done here. But I would also expect similar checkboxes (with parent label elements) to be a bit problematic. Not always and possibly not in the same way. But having this experience and going through the debugging of it should give you some ideas and discerning tools. Glad to hear it is working now. Have a great day!
But looking at 
I don’t know css as well as I know xpath myself so I miss some of that syntax as well. I tend towards referring back to this 
