[py] Expand element to be clickable

[maxtheaxe]

Previously only supported locator usage, added ability to pass element directly.

Thanks for contributing to Selenium!
A PR well described will help maintainers to quickly review and merge it

Before submitting your PR, please check our contributing guidelines.
Avoid large PRs, help reviewers by making them as simple and short as possible.

Description

• Added the ability to pass an element to element_to_be_clickable(), rather than just a locator.
• Checks argument type, and then operates accordingly (in the case of a locator arg, it is first converted/resolved to an element)

Motivation and Context

This feature already exists in the Java version, but does not in Python. It adds convenience.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• I have read the contributing document.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing tests passed.

I've never submitted a real pull request to anything before (or worked on a large project), so I'd appreciate any guidance necessary.

[CLAassistant]

All committers have signed the CLA.

[AutomatedTester]

We don't need to have a separate method here, we just need to do a test to check if it is a Tuple or a WebElement and then do the right thing. There are already examples in the file of how to do it. Please also add a test to py/test/selenium/webdriver/support/expected_conditions_tests.py

If you're up for a future PR, where there are duplications in the file for methods but differentiated by element or locator then we should deprecate them.

[maxtheaxe]

I was aiming to match that seemingly-established style of pairs of functions used elsewhere...now I'm curious why some ended up with the unnecessary duplication and some didn't. Regardless, I'm happy to clean that up in a future PR when I get the chance. Do you know off the top of your head if that duplication is limited to expected_conditions, or should I expect to walk through the entire python framework?

[maxtheaxe]

Is it possible that the existing implementations (those that you are suggesting I reference, that is) might benefit from a change in argument name, to reflect that they may be either locators or webElements? Leaving them named "locator" seems confusing, considering that elsewhere "locator" means literally a locator type, whereas here they can also be passed a webElement.

Again, this would be something to address in that future PR you spoke of, but it's just something that briefly threw me off when I was looking for the functions that accept either type.

[AutomatedTester]

Yes but we will need to deprecate them and remove them in the future after Selenium 4 has been released. Let's get this patch done and landed and we can take care of the rest later.

[maxtheaxe]

Was having a lot of trouble running the complete tests locally, despite following along here. They should pass this time, and I think we should be all set.

[maxtheaxe]

To be clear, I believe it passed everything it was supposed to. It's awaiting the signature of @p0deje because I synced with upstream partway through--I wasn't aware that it might cause problems.

[p0deje]

What's awaiting me?

[AutomatedTester]

@maxtheaxe Could you rebase your PR against trunk so we remove the Ruby changes that are unrelated.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[AutomatedTester]

Thanks for your PR!