Identification of 'main' window should be done via window handle

@shs96c

There is a convenient way of switching back to the main window using the Select Window keyword in Selenium2Library by providing a string main rather than a real locator. (The main value results in {"name":""} on the WD wire protocol.)

This has worked great thus far, however I recently ran into an issue using the keyword in this way with GhostDriver. Assuming the issue was with GhostDriver, I opened an issue against the project (https://github.com/detro/ghostdriver/issues/210).

However, after some additional discussion with Simon Stewart (@shs96c) he explained that while the WebDriver spec was intentionally left ambiguos in this area, the correct way of identifying windows is via the unique window handle itself. There is the potential for non-determinism if Window Title or Window Name are used because there might be duplicates.

Regarding how to implement this change, I am not sure what to suggest at this point. Potentially, storing the original window handle when a browser session is initiated, maybe. I'll dig into the S2L code a bit more in the coming days and hopefully suggest a good solution and possibly send a pull request.

ChromeDriver does not accept an empty name. This fails:

    Open Browser    http://www.github.com    gc
    Select Window

with error WebDriverException: Message: u"unknown error: 'name' must be a nonempty string\n (Session info: chrome=32.0.1700.102)\n (Driver info: chromedriver=2.8.241075,platform=Windows NT 6.1 SP1 x86_64)"

I confirm the error in Fedora Core 19 x64bit.
WebDriverException: Message: u"unknown error: 'name' must be a nonempty string\n (Session info: chrome=32.0.1700.102)\n (Driver info: chromedriver=2.8.240825,platform=Linux 3.12.8-200.fc19.x86_64 x86_64)"

According to 6.3 section in http://www.w3.org/TR/webdriver/ which says:

The ordering of the array elements is not defined, but may be determined by iterating over each top level browser window and returning the tabs within that window before iterating over the tabs of the next top level browser window. For example, in the diagram below, the window handles should be returned as the handles for: win1tab1, win1tab2, win2.

I gave my suggestion in #340:

        if criteria is None or len(criteria) == 0 or criteria.lower() == "null":
            browser.switch_to_window('')
            return

change the second line to:

    browser.switch_to_window(browser.get_window_handles()[0])

@divfor

@divfor - while this will likely work most of the time, the return of get_window_handles() is unordered. So while it may work now, there is no guarantee that the implementation won't change later such that the "main" window handle isn't generally returned in the first position.

@bmannix

@bmannix, would you take a look at @divfor's implementation in #349 and tell me what you think? I'd like some more eyes on it.

It is safe to think the first & top level browsing context, the root of tree-order of browsing contexts, will be at index[0] in list-order returned window handles. If a WD session has multiple top level browsing contexts, there will be multiple short lists joined together to form a single big list to return WD's local end, in this case the first top level browsing context will still be at index[0]. Though it is not official defined yet, I think it is safe to use get_window_handles()[0] to select 'main' window as it has been a fact that many existing usage are getting defined in spec.

Actually, from webdrivermonkeypatches.py you can find this:

    def current_window_is_main(self):
        return self.current_window_handle == self.window_handles[0];

There has not been activity for this issue for long time and we are planning to close the old issues if they are not anymore valid ones. If you feel that this is still valid issue, could you send an update. If update is not received in a month, we will assume that this is not anymore an issues and we will close this issue.

Closing issue due inactivity

Navigation Menu

Repository navigation

Identification of 'main' window should be done via window handle #213

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Identification of 'main' window should be done via window handle #213

Description

Activity

ombre42 commented on Jan 28, 2014

HelioGuilherme66 commented on Jan 28, 2014

divfor commented on May 11, 2015

bmannix commented on May 12, 2015

just-be-dev commented on May 12, 2015

divfor commented on May 14, 2015

aaltat commented on May 23, 2016

aaltat commented on May 22, 2017

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions