Repository navigation
[internal] feat(locator): doubleClick() and rightClick() for #134 - #1
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
TONGdamy
left a comment
TONGdamy
left a comment
There was a problem hiding this comment.
Looks good to me. I'd approve both commits as they are.
Commit 1: doubleClick() waits for the element to be visible and enabled, and rightClick() only waits for it to be visible. That's what BasePage already does (waitForClickable and waitForVisible), so users get the same behaviour from either API. Both go through whenReady, so they follow the seleniumboot#67/seleniumboot#68 contract. Only the first pointer move in the Actions sequence refers to the element, so a stale element fails before anything is clicked and a retry can't cause an extra click. The Javadoc is there on both methods, and its @throws lines match what whenReady actually throws.
Commit 2: the stale tests check what the maintainer asked for in seleniumboot#134. One asserts that the first gesture went to the stale element and the retry went to the fresh one. The other expects a TimeoutException caused by StaleElementReferenceException when the element never recovers, so a stale reference is never reported as success.
Before the upstream PR, the issue still needs a check against a real page in selenium-boot-test, because pointer gestures need a browser. The PR description should also note that the 4 CucumberQuarantineTest failures happen on an unmodified checkout too.
What & why
Internal review PR (fork only, not the upstream PR). This adds the pointer half of
seleniumboot#134:
Locator.doubleClick()andLocator.rightClick().press(Keys...),focus()and the docs will come in a separate internal PR onfeat/locator-actions-134-keyboard.Commits
feat(locator): add doubleClick() and rightClick() (#134)Both methods use Selenium's
ActionsAPI and go through the existingterminal-action helpers, so they follow the spike(locator): stale-proof click() — re-resolve on every poll seleniumboot/selenium-boot#67/feat(locator): terminal actions wait for presence and re-resolve on every poll seleniumboot/selenium-boot#68 contract: re-resolve on every
poll, and retry stale or not-yet-present elements until
timeouts.explicit.doubleClick()waits for visible + enabled (likeclick());rightClick()waitsfor visible (like
hover()). Javadoc with an example on both.test(locator): pointer actions follow the terminal-action contract (#134)New
LocatorActionsTestwith a shared data provider (8 scenarios × 2 actions) plusone
doubleClickenabled-wait test = 17 tests. Covers ready / late / hiddenelements, staleness during the readiness check and during the gesture, an element
that never appears, an element that stays stale (must time out, not succeed), and an
element that never becomes visible. It also checks the captured gesture: target
element, number of press/release pairs, and mouse button.
Verification
mvn clean verify(IntelliJ, macOS): 758 tests, 4 failures.CucumberQuarantineTest(Cucumber quarantine, unrelated toLocator). The same 4 fail on the base branch without these commits, so they arepre-existing in this environment.
LocatorActionsTesttests pass.Please check
reference being treated as success? (The maintainer asked for this specifically in feat(locator): press, focus, doubleClick, rightClick seleniumboot/selenium-boot#134.)
click()/hover()inLocator.java.Merge with Rebase and merge so both commits keep their authorship.
@TONGdamy could you review this when you have time? Thanks!