Add command to open a new top-level browsing context

[whimboo]

Currently opening a new tab/window can only be done by first loading a web page, which opens links with the target _blank. But then it is not clear if it will become a new tab or a new window. It all depends on the settings of the Browser in how _blank is handled.

To make it easier to open a tab or window, we should introduce a new window context related command like open (similar to close for closing). It would need an argument for the type of new context, and by default it should assume a new tab to save memory resources.

Please note that formerly key strokes like Ctrl+T and Ctrl+N were working, but those are not allowed anymore from within the context of the web page. Browsers like Firefox restrict those shortcuts.

[andreastt]

Thanks for filing this issue. I was surprised to find we didn’t have it filed already.

In our previous discussions there was resounding agreement that WebDriver should offer commands for creating new windows. let newWin = window.open(…) is not a great substitute because of security escalation issues.

[yucer]

In our previous discussions there was resounding agreement that WebDriver should offer commands for creating new windows.

@andreastt I suppose it would be good to offer also commands to handle Tabs, Bookmarks, Feeds, Downloads and all the other stuff that are common in all the browsers and do not belong to the document content.

[whimboo]

The webdriver spec is about accessing and operating with web content, and not controlling the browser itself. Everything outside of content, has to be handled somewhere else, and for now is up to the driver vendor in how and when to get it implemented.

Also please let us not drift away from the original request on this issue. Thanks.

[yucer]

The webdriver spec is about accessing and operating with web content, and not controlling the browser itself.

Sorry I was confused by the the goal defined in the standard:

WebDriver is a remote control interface that enables introspection and control of user agents. It provides a platform- and language-neutral wire protocol as a way for out-of-process programs to remotely instruct the behavior of web browsers.

Provided is a set of interfaces to discover and manipulate DOM elements in web documents and to control the behavior of a user agent. It is primarily intended to allow web authors to write tests that automate a user agent from a separate controlling process, but may also be used in such a way as to allow in-browser scripts to control a — possibly separate — browser.

Also the section 9 contain navigation commands like going Back and Forward over the browsing history.

If its all about operating the web content then this issue is out of scope, because controlling Tabs or Windows is not related to the behavior of the content, but the control of the browser instead.

[andreastt]

This issue is about adding a new command to open a new top-level browsing context. Let’s open separate issues for other requests.

[burg]

Can anyone propose a REST endpoint template for this command?

[yucer]

You might find this SO answer interesting.

There is / or was a target-new spec in CSS3. Was it really abandoned ?

If not, that would be the equivalent of the current target parameter for the javascript's windows.open or the anchor () html element.

Which endpoint handles that target attribute ? Is it the one for the Go command ?

One option could be:

• POST /session/{session id}/open/{target}/url

Where target could be the ones defined in target-new.

[yucer]

How many top level browsing contexts can be defined by session ?

Another option maybe easier to implement is to make an endpoint to clone the session or browsing context

• GET /session/{session_id}/copy/{target}

That might return the session_id of the session with the new browsing context where the user can make a normal click to continue.

Is that proposition too dummy to consider ?

[gsnedders]

Thanks for filing this issue. I was surprised to find we didn’t have it filed already.

In our previous discussions there was resounding agreement that WebDriver should offer commands for creating new windows. let newWin = window.open(…) is not a great substitute because of security escalation issues.

And even with newWin.opener = null, which is meant to disown the auxiliary browsing context, you can still distinguish this window from an actual top-level window (see https://freenode.logbot.info/whatwg/20181008#c1755708), which makes it undesirable from a testing point of view (given you want something undistinguishable from what the user does).

Apparently <a href="about:blank" rel="noopener"></a> has the right semantics, though (though isn't supported by Edge 🙁).

[gsnedders]

Bah, noopener still has differences with link targeting.

[shs96c]

It feels like a POST to /session/{sessionId}/window/handles (with the return value being the new window's handle) would be the best end point, @burg

[shs96c]

We agreed at TPAC to new endpoint as a POST to /session/{sessionId}/window/handles that takes a hint indicating the context type (eg. tab/window/potentially thing in the future). The return value should be the window handle that was opened and the context type that was created.

[whimboo]

Note that support for this command is about to land for Firefox (see https://bugzilla.mozilla.org/show_bug.cgi?id=1504756).

Now I will start working on geckodriver support, and at the same time will add this new feature to the webdriver client, and create all the required webdriver tests. This work will happen on https://bugzilla.mozilla.org/show_bug.cgi?id=1509513.

[foolip]

@JohnChen0 is there a ChromeDriver bug for implementing this? We'd like to use it in web-platform-tests :)

[JohnChen0]

@JohnChen0 is there a ChromeDriver bug for implementing this? We'd like to use it in web-platform-tests :)

I created https://crbug.com/chromedriver/2690 for ChromeDriver.

[foolip]

Thanks!

[whimboo]

FYI the support for this command has been landed in Marionette/Firefox 66 now.

In https://bugzilla.mozilla.org/show_bug.cgi?id=1509513 I will take care of adding support to geckodriver, and at the same time I will add a good amount of WebDriver tests.

[whimboo]

Please note that the wdspec tests for the new window command have been landed two days ago via web-platform-tests/wpt#14926. Test results can be found at https://wpt.fyi/results/webdriver/tests/new_window?label=master&label=experimental.

We are trying to release geckodriver 0.24 in January which then will add support for that command in Firefox 66 which is soon in beta.

[andreastt]

Do we know if there are issues filed upstream on important clients (Selenium, webdriver-io) for adding client APIs for the new window command?

Presumably that work can be done in parallel to shipping geckodriver 0.24, so we achieve the effect that clients are ready when the driver is.

[burg]

Support for the spec'd endpoint will be included in an upcoming Safari Technology Preview.

[christian-bromann]

Do we know if there are issues filed upstream on important clients (Selenium, webdriver-io) for adding client APIs for the new window command?

Created webdriverio/webdriverio#3383 and will release it today.

Update:
released with [email protected] (https://webdriver.io/docs/api/webdriver.html#createwindow)

[whimboo]

Do we know if there are issues filed upstream on important clients (Selenium, webdriver-io) for adding client APIs for the new window command?

I filed SeleniumHQ/selenium#6873 for the bindings covered by the Selenium repository.