Window object serialisation

We currently serialise elements that are returned from Execute Script
as so called “web elements” using web element references:

    http://w3c.github.io/webdriver/webdriver-spec.html#dfn-web-element-reference

It would solve a lot of problems if we decided to apply a similar
serialisation scheme for Window objects.  A concrete use case is
opening a new window, if we imagine the following JS being evaluated
by WebDriver:

    let newWindow = window.open("");
    return newWindow;

This would return the window’s handle, which could then be passed
directly to Switch To Window.  My suggestion is to reuse exactly the
same architecture we have in place for marshalling elements across the
wire by returning an object with a special-meaning UUID key mapped to
the handle, as such:

    {"<uuid>": "<string equal to window handle>"}

Although it is not possible to Switch To Window for every Window
object, for example <iframe>’s and other non-top level browsing
contexts, this in line with the WebDriver definition of “window”: The
user already needs to know whether a window handle should be used with
Switch To Window or Switch To Frame.

I also propose we make it possible to distinguish between top-level
browsing contexts and nested browsing contexts (<iframe>) by
identifying them with two different UUIDs, so that strongly typed
client languages can infer relevant type information for interfaces,
traits, &c.

This suggestion is not specifically aimed at solving the infinite
recursion problem of returning a Window object from an evaluated
script, although it helps what I think is the most common issue where
drivers tend to hang.  I think the recursion complexity problem is a
matter to be solved independently.

Received on Wednesday, 6 April 2016 18:22:38 UTC