Repository navigation
[Feature] publish _selector attribute of Locator and internal: selectors #23992
Description
Hi (this is René from Robot Framework)
Introduction
i am one of the developers of Robot Framework Browser; the Playwright (node.js) based keyword library that is really gaining more users.
We have currently ~10% of the download numbers that Playwright Python has. (~90.000 / month)
I am writing that issue to create awareness and also request that a set of features that we depend on shall not be dropped. And some other maybe published to public api.
Robot Framework Browser is, because it is Keyword-Driven, imperative/procedural. That means we are calling functions like Click or Type Text with a selector as its first argument.
Therefore it is vital for us that the string based creation of Locator objects stays active.
Please never deprecate stuff like page.locator("div.some >> text='hello'");
Feature Request 1: _selector
Furthermore it would be nice to publish the locator._selector attribute as part of the public API.
We have keywords like Get Elements which return a handle to a Locator object that we store on the node side of our library. It would be better for many use cases to return the selector string in these cases.
Having that as part of the public API would give us more safety that we can rely on this.
Feature Request 2: internal:
the "new" getByRole or getByLabel etc. functions are interesting and are demanded by our users. We know that these are internally translated to selector strings and we would really like to use these selector strings officially as well.
therefore it would be awesome if you could publish the internal selectors as well.
page.getByRole("heading", { "name": "Login" });Is equivalent to
page.locator('internal:role=heading[name="Login"i])would be nice, if we could get in touch and discuss our usage of Playwright as well.
cheers
René
Activity
Snooz82 commentedon Jul 2, 2023
By the way:
similar situation is this:
To give our users the possibility to pierce frames with a selector string, we added a special concatenation syntax with
>>>.So for example the first
<p>in the iframe with name "right" would be:internally we split it, then first fetch the frame and then the element, basically only to use public APIs.
like:
This makes our code unnecessary complex.
if
internal:control=enter-framewould be public API, we could rely on it.pavelfeldman commentedon Jul 3, 2023
❤️
🤝
As a part of our semver commitment we have no intention to break our users within the major versions. And we don't plan to move to 2.* in the foreseeable future.
I don't think it is feasible for us to commit to exposing the _selector since it will contain internal selectors (roles, etc) that are considered an implementation detail and can change release to release.
This would be the same as above, string representation of these is considered to be an implementation detail and a subject to change.
Snooz82 commentedon Jul 4, 2023
i think we would be totally fine with having the most
internal:selectors being a subject of change.I would not recommend to any user to use them directly.
But the selector attribute of a Locator is a good way to string serialize a Locator object. At least the relevant information.
So if we do
page.getByRole(xxx)._selectorand sends this information to our python side (we are using Playwright node and communicate between Python and node with gRPC) in can be store in a variable there and used later.Snooz82 commentedon Jul 4, 2023
And could it maybe a valid feature request if at least the "frame opening selector" could be something considered public/introduced?
Not necessarily the
internal:control=enter-framebut maybe justcontrol=enter-frame?I think this is a valuable feature itself.
Because also users of playwright, cypress, etc. do store their selectors in variable files and giving them a possibility to also define a frame opening in this string selector would be a benefit of playwright compared to some others.
The Shadow Dom handling is already one of playwrights USPs.
I think a "frame opener" could be another one.
pavelfeldman commentedon Jul 4, 2023
I'm not sure I follow, but note that there are no guarantees on the presence of the
_selector, so it can disappear at any moment.That would be the same as above, we consider frame locator implementation to be an implementation detail.
I'll close this feature request of exposing
_selectoras won't fix to make sure our intent is clear. I understand that this might be suboptimal for your application, but I don't think we are ready to commit to exposing_selectorof the programmatically composed locators at this point.Snooz82 commentedon Jul 5, 2023
😔