I was disappointed when this changed as well. It actually broke some tests.
I was interacting with 5 widgets that could only be identified by a common tag. After getting a list of these 5 items, I needed to track them uniquely while performing various actions. This worked well when it returned element ID.
After upgrading, it began returning an xpath which included an index to identify them. Depending on the action, sometimes the list may change from 5 to 4. Index made it impossible to ensure the right one got removed from the list. All I would know is the list shrunk.
A bit hard to explain since it is kind of product specific. There could potentially be thousands of widgets in this list so it wasn’t realistic to give them unique tags.
Anyway all that to say I would be interested to know if there is a way to do this as well.
One of the great things about Robot Framework is it’s easy to build keywords
In a situation like this you can create your own keyword that provides the old behaviour to your test case rather then rewriting all your test cases, just change the test case to use your own keyword.
If I understood your issue, something like this will probably do what you need:
*** Settings ***
Library Browser
Library Collections
Suite Setup Open Browser https://robotframework.org/ chromium
test Teadown Close Browser
*** Test Cases ***
Get Element Id Example
Go To https://www.google.com/
${myid}= Get Element Id css=.A8SBwf textarea
Get Elements Ids Example
Go To https://robotframework.org/
${myids}= Get Elements Ids css=.pt-3xsmall h2
*** Keywords ***
Get Element Id
[Documentation] Returns the id of the selected element
[Arguments] ${Selector}
${element}= Get Element ${Selector}
${id}= Get Property ${element} id
[Return] ${id}
Get Elements Ids
[Documentation] Returns the id of the selected elements
[Arguments] ${Selector}
@{Ids}= Create List
${elements}= Get Elements ${Selector}
FOR ${element} IN @{elements}
${id}= Get Property ${element} id
Append To List ${Ids} ${id}
END
[Return] ${Ids}
You didn’t provide a link to the page for me to check so i can’t really say. But as im replying with my phone from Singapore transit lounge i probably couldn’t check now anyway.
The example I gave worked with those urls in my example when I wrote it. Try it now with those urls and see if it works, if not I can check tomorow when i get home. If it works with those example urls, then it might be something to do with the site your testing.
day n - ran test against app x with browser library 15.1.0 and things worked
day n+210 - ran test against app x with browser library 17.3.0 and things didn’t work
Is that there are too many unknowns to make a fair comparison, and we can’t tell on this alone if the change occurred in app x, browser library, an underlying browser (e.g. chrome) or somewhere else.
A manual check with dev tools is easy to do and check if the page elements have the id on them now, if not it’s probably something that changed in your app, if possible can you roll back your app to the older version and run the test with 17.3 on the older version of your app, this would confirm it’s an app issue.
Alternatively roll one of your test machines back to browser library 15.1.0 and run the same test on your current version of your app, if it fails that will also confirm it the app, if it passes then it indicates the problem is elsewhere.
There are quite a few variables here so if it’s not the app your testing that’s changes there will be a bit of troubleshooting to find the problem:
There are many browser library versions between 15.1.0 and 17.3.0
browser library calls playwright so all the playwright versions also need to be checked
playwright calls the browser itself (chromium?) and there probably have been many browser version changes in that time.
If your sure it’s not your app, then it would be helpful to the devs of browser library to provide an example they can use to reproduce this issue as someone will need to roll forward version by version one at a time from 15.1.0 to 17.3.0 to find which version introduced the issue. Finding where the bug first occurred and which change caused it is 50+% of bug fixing.