Bug 291586 – [WebDriver][GLIB] Incorrect browsing context check after moving to a frame-less page

• Component: WebDriver
• Status: RESOLVED INVALID

[Lauro Moura]

imported/selenium/py/test/selenium/webdriver/common/frame_switching_tests.py::test_should_focus_on_the_replacement_when_aframe_follows_alink_to_a_top_targeted_page

Test code:

    pages.load("frameset.html")
    driver.switch_to.frame(0)
    driver.find_element(By.LINK_TEXT, "top").click()

    expectedTitle = "XHTML Test Page"

    WebDriverWait(driver, 3).until(EC.title_is(expectedTitle))
    WebDriverWait(driver, 3).until(EC.presence_of_element_located((By.ID, "only-exists-on-xhtmltest")))

Test is returning `"no such window"` inside `Session::findElements` due to `m_currentBrowsingContext` being null. This var is cleared by `Session::waitForNavigationToComplete` completion handler after moving away to a frame-less page.

But `m_currentBrowsingContext` is allowed to be null in a number of scenarios, defaulting to the main frame inside the browser. For example, it's usually passed as the "frameHandle" parameter in methods from `Automation.json`:

> "frameHandle": The handle for the frame in which to search for the frame. The main frame is used if this parameter empty string or excluded.

And `Session::findElements` code indeed expects this behavior, checking if m_currentBrowsingContext is null or not.

So, looks like the correct check would be whether `m_toplevelBrowsingContext` is valid nor not. On top of `Session::findElements`, there are other `Session` methods with this behavior, like `getActiveElement`, `executeScript`, etc.

[Lauro Moura]

Actually, the check is correct per the spec, as seen in the `find_element/find.py` tests:

```
def test_no_browsing_context(session, closed_frame):
    response = find_element(session, "css selector", "foo")
    assert_error(response, "no such window")
```

Related spec links:

- Spec PR: https://github.com/w3c/webdriver/pull/1543
- Related tests: https://bugzilla.mozilla.org/show_bug.cgi?id=1493108
- WebKit update to match behavior: https://commits.webkit.org/230029@main

IIUC, the client needs to ensure a valid "current browsing context" is selected in these scenarios instead of the driver "implicitly" falling back to the top level context. For example, by switching explicitly after eventually closing the current one. So the issue is in the Selenium test (which actually is marked as fail in other browsers)

Closing as invalid, sorry for the noise.