Specify behavior for browsingContext.close when closing the last browsing context

[juliandescottes]

Followup to #170

There is an open issue about the behavior when closing the last browsing context.
See comments in #170 for more context, but the discussed options were:

• always end the session and close the browser (same as WebDriver HTTP)
• always end the session, but what happens to the browser is unspecified
• expose a capability to keep the browser open after closing the last browsing context. If provided (and supported), the browser and session would remain alive after closing the last browsing context. If not, end the session and close the browser

[whimboo]

Note that for our WebDriver classic implementation (Marionette) in Firefox we recently added a windowless mode, which means that on platforms that support running an application without a window open (which is MacOS only) we do not shutdown the browser when closing the last window. But this is a special mode and can be entered with the moz:windowless capability as specified for the New Session command.

Note that under such a condition none of the WebDriver classic commands work because we run a check for an open window, and if none is available we raise a no such window error. For WebDriver BiDi commands we pass-in a realm or browsing context reference to indicate where the command has to run. If no browsing context is available none of the commands could be run as well. As such the only available command in such a situation would be browsingContext.create?

[jgraham]

One can imagine other commands would make sense including any configuration commands e.g. session.subscribe.

Given that we have a clear usecase for this I think we should also support it in bidi. I think the question is whether it ends up as a configuration option in the capabilities or if we just allow you to get into the state where there are no windows open, where supported.

I think my prefernce is for the latter; you can still implement the webdriver-classic behaviour by noticing that the last window closed and ending the session if the browser is still alive.

[jimevans]

Question specifically for browser vendors: do you typically care whether a browser host process is forceably killed? Consider the use case of a local end library that exclusively supports bidi-only sessions (no WebDriver classic to fall back on; no driver executable to manage). Such a library would be responsible for launching the browser with the proper arguments to enable WebDriver bidi communication, and starting and managing a session with that browser. When the library is through with that browser, and terminates the session, how does the library (without extensive knowledge about what processes the browser may or may not have spawned during the session) leave the target environment in the proper pre-execution state? That is to say, how does the library make sure there are no zombie or abandoned processes still running once the test is done?

[jgraham]

Killing the browser process can end up with an unclean shutdown, which may skip some shutdown logic (depending on the browser). That could mean e.g. not all runtime changes are written to the browser profile, or e.g. we miss out on leak logging (that example is maybe more relevant to browser vendors, but it's an example of why gecko at least will need a way to trigger a clean shutdown for our CI).

[jimevans]

@jgraham This, in fact, is why I bring it up. Seems to me we'd want a command in the protocol to gracefully shut down the browser.

[jgraham]

That's #119

[sadym-chromium]

An argument for the capability instead of always-allow is differences in WebDriver Classic and BiDi behavior, which can easily lead to uncertain state depending on the protocol via which the page was closed. From this perspective adding capability shared between Classic and BiDi with default "end session and browser if the last browsing context is closed" seems the least confusing.