[Feat]: RelativeBy functionality from Selenium 4

[aaronportier]

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. I have radio buttons and check boxes next to text that contains automation IDs it would be nice to tell my app left of instead of creating automation IDs for checkboxes.

Describe the solution you'd like
Selenium 4 brought RelativeBy functionality. I would love to use that in appium.

Describe alternatives you've considered
Automation IDs everywhere on everything.

Additional context
I see lots of deprecation for newer Selenium functionality but not a whole lot of new and added functionality that Selenium should bring.

[Dor-bl]

Related article: https://saucelabs.com/resources/blog/selenium-4-relative-locators

[mykola-mokhnach]

These locators rely on the native implementation. In case of selenium/browser automation it is easy to do something like that since under the hood they have css location. As a result, relative locators could easily be transformed into native ones.
There is completely different story on mobile platforms though. Neither XCTest nor UIAutomator frameworks implement the concept of relative locators. For us, as backend developers, this means we'd need to map such locators into xpath ones, as it is the only locator type, which supports the idea of search axes. It's not only failry complicated task, but also a slow one, since xpath is the slowest location strategy (it's completely "artificial" and is not supported natively, especially in case of XCTest, where various XPath locators may take 10x to 100x more time in comparison to native ones)

[Dor-bl]

Let alone we can't easily inherit from this class (RelativeBy) since it's not abstract.
@titusfortner @nvborisenko is there a plan for making RelativeBy abstract? Or is there a good reason behind it

[nvborisenko]

static members, what are not considered as inheritable? In any case we are open for any non-breaking changes (as quick win). Please propose your ideas, I don't see barriers for changes (breaking changes?..).

[nvborisenko]

Ah, forgot to answer on your question. RelativeBy will not be abstract in discoverable future, it is concrete type. I don't see problems to make some parts as virtual.