Problem with Get Element, cascaded selectors and/or *-prefix in Browser version 10+
See original GitHub issueDescribe the bug
Prior to Browser library version 10, I used Get Element and the * character to capture the parent element containing given text (Practically identically like explained under the Cascaded selector syntax in the keyword documentation). I would later on pass that element around and use it as a selector to extract and assert information. This interaction worked in version 9.0.2, but in later versions it seems that Get Element doesn’t resolve to the element anymore, resulting in the future use of the retrieved variable not working as previously intended.
To Reproduce I’ve managed to reproduce the behaviour with the following page and test case. Pardon the simplicity.
page.html
<ul>
<li>
<button>
<h3>namegoeshere</h3>
<p>42</p>
<p>24</p>
</button>
</li>
<li>
<button>
<h3>anothernamegoeshere</h3>
<p>foo</p>
<p>bar</p>
</button>
</li>
</ul>
test.robot
*** Settings ***
Library Browser
*** Test Cases ***
Get Element problem test
New Page ${EXECDIR}\\page.html
# note the * -character. Again, see the Cascaded selector syntax in the keyword documentation as well.
${button_element}= Get Element *xpath=//button >> text="namegoeshere"
${val}= Get Text ${button_element} >> xpath=//p[1]
should be equal ${val} 42
Expected behavior
the ${button_element} variable should get resolved to the first button element in the example page, containing the h3 element with the text namegoeshere and the p elements. Then that variable should be used as selector in the next line, retrieving the text 42 in the p element. The following should be equal assertion in the test case should then succeed. I’ve confirmed this to work with Browser library version 9.0.2.
However in Browser library version 10+ (in this case 10.1.0) the Get Text fails on a TimeoutError.
TimeoutError: locator.elementHandle: Timeout 10000ms exceeded.
=========================== logs ===========================
waiting for selector "*xpath=//button >> text="namegoeshere" >> xpath=//p[1]"
============================================================
This issue is present in all 3 browser engines, regardless of headless mode. Python version 3.10, Node version 14.18.1.
Desktop (please complete the following information):
- OS: Windows 10
- Browser confirmed on all browser engines
- Version 21H1
Additional context Was the desired behavior I’ve described even intended in the first place🤔
Issue Analytics
- State:
- Created 2 years ago
- Comments:7 (1 by maintainers)

Top Related StackOverflow Question
Thanks a ton @aaltat for doing the research and getting back to this issue! Let’s hope a fix is coming to the playwright side of things in the future.
I might have an idea what causes this, but I need to do some experiments with Playwright.