Difference between 17.3.0 and 15.1.0 in Get Element


We have a test that when used with 15.1 version of browser library returns element id when using Get Element keyword

But on 17.3 Get Element keyword is returning xpath.

Is there a possibility to force Get Element to return element id instead of xpath on new version?


Currently there is not a way. Can you explain why you would prefer an element ID, instead of the selector?


Thank you for the info.

We are using element id with > button and with xpath this does not work :wink: It’s just the way we have our tests created.

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.

Hi @TomekWro and @asdf

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}

	[Return] 	${Ids}

Hope that helps,



I’ve updated the version again and now i need to make it work :wink:

I’ve tried your solution but it does not return ID on element

Any ideas why it may happen?


Hi Tomasz,

Not sure does your element actually have an id?

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.



The url is rather internal, as for the id, on v15 it works and shows id=somethingsomething, maybe it’s not really “id” attribute?

I will try to find out :slight_smile:

Hi Tomasz,

The problem with these types of comparisons:

  • 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.

Hopefully this helps you narrow it down,