- From: Seva Lo <vlotoshnikov@gmail.com>
- Date: Tue, 16 Jun 2015 11:51:23 -0700
- To: Andreas Tolfsen <ato@mozilla.com>
- Cc: public-browser-tools-testing <public-browser-tools-testing@w3.org>
- Message-ID: <CACD1K93wAhNA0h1be-2u9ZZ0Vet3trm7bh7aM02OMYa93qhGFg@mail.gmail.com>
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. >
Received on Tuesday, 16 June 2015 18:52:06 UTC