Re: Making Delete Session an atomic commad

Because of the reasons you mentioned in the last paragraph and because of
the amount of code that's out there with the assumption that "delete
session" does what it does, I think this is problematic.

Do you think a new command with distinct semantics (e.g. Detach From
Session) could address the issue? There could be a capability indicating
whether that command is supported by the current session. Note that some
setups with intermediate nodes may not be able to support it even if the
downstream remote end(s) do support it.

Seva


On Tue, Jun 9, 2015 at 2:03 PM, Andreas Tolfsen <ato@mozilla.com> wrote:

> Currently calling Delete Session also involves discarding all open
> top-level browsing contexts.  Unfortunately the side-effect of this is that
> you cannot reconnect a WebDriver session to UA’s same state.
>
> Many of the existing Selenium- and WebDriver implementations make a
> distinction between closing the session and steps that might involve
> terminating the browser process.
>
> Because the same effect can be achieved on the client API side through
> iterating over the windows and closing each one individually, I’d like the
> propose making Delete Session atomic, by not having it implicitly close the
> top-level browsing contexts on your behalf.
>
> Since there may be implementation-specific post steps tied to deleting a
> session, such as terminating the browser process, this in practice would
> mean that a UA could choose to decide whether to close the contexts or
> not.  It would, however, mean that one could, for some UA’s, “continue”
> from the same state a WebDriver session left it in.
>