Repository navigation
feat(locator): add press, focus, doubleClick and rightClick (#134) - #188
Merged
shossain786 merged 5 commits intoOct 21, 2026
Merged
Conversation
BasePage already offers doubleClick/rightClick, but Locator did not, so users had to drop out of the Locator API for these gestures. Both methods perform the gesture with Selenium's Actions API and go through the existing terminal-action helpers, so they follow the same contract as click() and hover() (seleniumboot#67/seleniumboot#68): the element is re-resolved from scratch on every poll, and stale or not-yet-present elements are retried until timeouts.explicit. A StaleElementReferenceException thrown while the gesture is performed is retried as well, rather than being treated as success. - doubleClick() waits for the element to be visible and enabled, like click(). - rightClick() waits for the element to be visible, like hover(). Each method has Javadoc with a usage example. Tests follow in the next commit. Refs seleniumboot#134
…eleniumboot#134) Add LocatorActionsTest, which checks that doubleClick() and rightClick() honour the same terminal-action contract as click() (seleniumboot#67/seleniumboot#68). The tests mock the driver as Interactive so the Actions sequences can be captured, and set timeouts.explicit to 1s to keep the timeout cases fast. Each pointer action is run through a shared data provider covering: - a ready element: the gesture is performed once on one lookup, and the element is never cleared or plain-clicked - an element that appears later: the locator re-resolves first - an element that is hidden at first: the action waits for it to become visible - an element that goes stale during the readiness check: a fresh element is resolved and used - an element that goes stale during the gesture: the gesture is retried on a freshly resolved element - an element that never appears: LocatorException with a TimeoutException cause, and no gesture is performed - an element that stays stale during the gesture: the action times out instead of reporting success - an element that never becomes visible: times out without acting A separate test checks that doubleClick() waits until the element is enabled. The successful cases also decode the captured gesture to check the target element, the number of press/release pairs (2 for doubleClick, 1 for rightClick) and the mouse button (left for doubleClick, right for rightClick). The data provider is shared so that the keyboard and focus actions can be added to the same matrix. Refs seleniumboot#134
Contributor
|
Merged, thank you @TONGdamy and @crystalmountain666. Clean implementation, and the tests cover the stale-element retry contract well. This closes #134. |
Merged
shossain786
added a commit
that referenced
this pull request
Oct 21, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What & why
Locatorhad nodoubleClick(),rightClick(),focus()orpress(Keys...), so tests had to drop back toBasePageor raw WebDriver for these interactions. This PR adds all four so theLocatorAPI is the only place users need to look.All four are terminal actions and follow the contract from #67/#68: the locator is re-resolved from scratch on every poll, and stale or not-yet-present elements are retried until
timeouts.explicit. AStaleElementReferenceExceptionthrown while the action is performed is retried as well, so a stale reference is never treated as success.doubleClick()waits for the element to be visible and enabled, likeclick()andBasePage.doubleClick().rightClick()waits for the element to be visible, likehover()andBasePage.rightClick().press(Keys...)sends the keys to the element without clearing it.focus()moves focus to the element with JavaScript.Closes #134.
Type of change
Checklist
mvn clean verify) (mvn clean verify -Dgpg.skip; GPG signing skipped locally)@SeleniumBootApipublic APIs (or a major version bump is justified below)docs-site/)Notes for reviewers
Commits. The change is split into five commits:
doubleClick()/rightClick(), their tests,press(Keys...)/focus(), their tests, and the docs (a changelog entry indocs-site/docs/changelog.mdand one line in the locators guide).Tests. The new
LocatorActionsTestruns all four actions through a shared data provider covering eight scenarios: a ready element, an element that appears later, an element that is hidden at first, staleness during the readiness check, staleness during the action, an element that never appears, an element that stays stale (it must time out instead of succeeding), and an element that never becomes visible. A separate test checks thatdoubleClick()waits until the element is enabled. For the pointer actions, the tests also decode the captured gesture to check the target element, the number of press/release pairs and the mouse button. The tests are in their own file, followingLocatorDragToTest.Verification.
mvn clean verify -Dgpg.skipon the branch rebased onto the currentmaster(748d9b6), macOS: BUILD SUCCESS, with 789 tests run and 0 failures, 0 errors and 0 skipped. That is 756 existing tests plus the 33 newLocatorActionsTesttests. The Javadoc jar for the new methods also builds without errors.Co-authored by @crystalmountain666 and @TONGdamy.