[Feature] publish `_selector` attribute of Locator and `internal:` selectors

[Snooz82]

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é

[Snooz82]

By the way:

similar situation is this:

iframe[name="right"] >> internal:control=enter-frame >> p >> nth=0

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:

iframe[name="right"] >>> p >> nth=0

internally we split it, then first fetch the frame and then the element, basically only to use public APIs.
like:

page.frameLocator('frame[name="right"]').locator('p >> nth=0')

This makes our code unnecessary complex.
if internal:control=enter-frame would be public API, we could rely on it.

[pavelfeldman]

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.

🤝

Please never deprecate stuff like page.locator("div.some >> text='hello'");

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.

Feature Request 1: _selector

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.

Feature Request 2: internal

This would be the same as above, string representation of these is considered to be an implementation detail and a subject to change.

[Snooz82]

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)._selector and 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]

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-frame but maybe just control=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]

So if we do page.getByRole(xxx)._selector and 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.

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.

And could it maybe a valid feature request if at least the "frame opening selector" could be something considered public/introduced?

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 _selector as 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 _selector of the programmatically composed locators at this point.

[Snooz82]

😔