fix: allow newWindow when the active window was already closed#17766
Open
mvanhorn wants to merge 1 commit into
Open
fix: allow newWindow when the active window was already closed#17766mvanhorn wants to merge 1 commit into
mvanhorn wants to merge 1 commit into
Conversation
|
|
Contributor
PR Summary by QodoFix RemoteWebDriver.newWindow when the currently-focused window is already closed
AI Description
Diagram
High-Level Assessment
Files changed (2)
|
Contributor
Code Review by Qodo
Context used✅ Compliance rules (platform):
18 rules 1. Outdated newWindow unit test
|
![qodo-code-review[bot]](https://avatars.githubusercontent.com/in/484649?s=60&v=4){kind=small}
Comment on lines
+1319
to
+1323
| Response response = execute(DriverCommand.SWITCH_TO_NEW_WINDOW(typeHint)); | ||
| String newWindowHandle = | ||
| ((Map<String, Object>) response.getValue()).get("handle").toString(); | ||
| switchTo().window(newWindowHandle); | ||
| return RemoteWebDriver.this; |
Contributor
There was a problem hiding this comment.
1. Outdated newwindow unit test 🐞 Bug ≡ Correctness
RemoteTargetLocator.newWindow no longer calls GET_CURRENT_WINDOW_HANDLE, but RemoteWebDriverUnitTest#canHandleSwitchToNewWindowCommand still asserts that command sequence via strict in-order verification, so this test will fail. Update the unit test expectations to match the new behavior.
Agent Prompt
### Issue description
`RemoteWebDriverUnitTest#canHandleSwitchToNewWindowCommand` still expects `GET_CURRENT_WINDOW_HANDLE` to be issued before `SWITCH_TO_NEW_WINDOW`, but the PR removed that call from `RemoteTargetLocator.newWindow`, causing the unit test to fail.
### Issue Context
The test uses `WebDriverFixture.verifyCommands`, which enforces a strict in-order match of the executed commands.
### Fix Focus Areas
- java/test/org/openqa/selenium/remote/RemoteWebDriverUnitTest.java[287-299]
### What to change
- In `canHandleSwitchToNewWindowCommand`, remove the expectation for `DriverCommand.GET_CURRENT_WINDOW_HANDLE`.
- The expected sequence should now be:
1) `DriverCommand.SWITCH_TO_NEW_WINDOW` with `{type: "tab"}`
2) `DriverCommand.SWITCH_TO_WINDOW` with `{handle: "new window"}`
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
Comment on lines
+1319
to
+1323
| Response response = execute(DriverCommand.SWITCH_TO_NEW_WINDOW(typeHint)); | ||
| String newWindowHandle = | ||
| ((Map<String, Object>) response.getValue()).get("handle").toString(); | ||
| switchTo().window(newWindowHandle); | ||
| return RemoteWebDriver.this; |
Contributor
There was a problem hiding this comment.
2. No focus restore on error 🐞 Bug ☼ Reliability
Removing the try/catch means newWindow no longer attempts to restore the previously focused window when a WebDriverException occurs after issuing the new-window command, potentially leaving the session focused on an unexpected window even though the call fails. This is an exception-path behavior regression versus the prior implementation and differs from other switch logic that restores focus after fallback attempts.
Agent Prompt
### Issue description
`RemoteTargetLocator.newWindow` no longer performs any recovery on `WebDriverException`. If the remote end has already switched focus as part of the new-window command, and a subsequent step throws, the session may be left focused on an unexpected window.
### Issue Context
The original pre-fetch of `getWindowHandle()` was removed to support the legal state where no window is focused. You can preserve that fix while still supporting recovery by capturing the original handle only when available (and skipping recovery when it is not).
### Fix Focus Areas
- java/src/org/openqa/selenium/remote/RemoteWebDriver.java[1317-1324]
### What to change
- Reintroduce a guarded recovery pattern:
- Attempt to capture `original` using `getWindowHandle()` inside a `try/catch (NoSuchWindowException)` (or broader) and set `original = null` if unavailable.
- Wrap the new-window flow in `try/catch (WebDriverException ex)`.
- In the catch block, if `original != null`, attempt `switchTo().window(original)` in a best-effort way (swallow/ignore failures during restore), then rethrow `ex`.
- This keeps the PR’s main fix (don’t fail when no window is focused) while preserving prior exception-path stability when an original handle exists.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
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
3 participants
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.
🔗 Related Issues
Fixes #17754
💥 What does this PR do?
RemoteWebDriver$RemoteTargetLocator.newWindow(WindowType)no longer throwsNoSuchWindowException: target window already closedwhen the caller has already closed the currently-focused window. PreviouslynewWindowbegan by callinggetWindowHandle()to remember the current window (so it could switch back on failure), which threw in the legal W3C state where the driver is not focused on any open window. The reporter's repro —newWindow(WINDOW)→switchTo().close()→newWindow(WINDOW)— now succeeds as long as other windows remain open.🔧 Implementation Notes
Removed the leading
getWindowHandle()call and the try-catch that restored that stored handle. Switching to a just-created window handle is expected to succeed; in the rare case it fails, the driver is still on its previous handle, so there is nothing to restore — the stored handle only existed to serve a restore path that was never actually reachable in a useful way, and it was the thing that threw when no window was focused. The new-window creation and switch remain; only the redundant pre-fetch and restore wrapper are gone.🤖 AI assistance
💡 Additional Considerations
The reporter noted the try-catch and the handle it depended on were unnecessary; this change reflects that. Added a regression test covering the close-active-window-then-newWindow sequence.
🔄 Types of changes