Re: Window object serialisation

If there are no concerns over this by the end of tomorrow I will be merging
Andreas' PR on Friday.

David

On 26 April 2016 at 16:20, Andreas Tolfsen <ato@mozilla.com> wrote:

> Sorry for the lack of reply, but I have been on holiday in Iceland.
>
> On 20 April 2016 at 21:06, Simon Stewart <simon.m.stewart@gmail.com>
> wrote:
> > 1) You say that this would solve a lot of problems. Are there other
> concrete
> > examples? In the example you give, the standard idiom is to poll the
> > webdriver until we find a new window handle, which would avoid the need
> to
> > implement another serialisation mechanism in every driver.
>
> It was writing WebDriver specification tests for the Get Current URL
> command that made me realise how much more elegant it would be if one
> could get directly at the window handle for the current browsing
> context.
>
> In
> https://github.com/w3c/web-platform-tests/pull/2799/files#diff-d5cbca9a83b6b30e632cabec092d052eR48
> a script is injected to open another top-level browsing context and
> the only way we can get the new window handle is to diff the union of
> a set of window handles before and after the window appears.
>
> Instead, because `window.open` returns the new Window object so it is
> possible to pass messages between windows of the same application,
> Execute Script could serialise that so it could be used in the next
> call to Switch To Window.
>
> Another use case is to have the ability to check Window object
> relationships from within the current browsing context, i.e. to test
> relationships between `window.parent`, `window.top`, `window.opener`,
> `window.frames[N]`, and so on.
>
> Switching in window- and frame hierarchies is probably also the most
> expensive scenario to replicate with existing primitives. Without
> knowing the document structure upfront (maybe because it is
> unpredictable), getting at which context is the parent of the current
> context is quite hard without the ability to return `window.parent`
> and get the parent browsing context’s window handle.
>
> Because WebDriver has no concept of structural relationships between
> windows, or even of the document, it makes perfect sense to rely on
> the DOM to provide this for us, as we do with DOMElements and Nodes.
> And to be clear, this would not exactly be adding “another
> serialisation mechanism” as it would re-use the very same framework we
> have in place for web elements.
>
> I also think there is a case for providing window serialisation seen
> from the point of view that Switch To Window inadvertently triggers
> DOM events on focus and blur, and that this approach would let you get
> a browsing context’s handle without activating these.
>
> Furthermore it would significantly cut the number of command/response
> roundtrips for the most common window manipulation scenarios I’ve
> described here.
>
> > 2) Relatedly, do we have this implemented in more than one driver right
> now?
> > Or is this just a suggestion at this point?
>
> It’s not implemented in any drivers at this point.
>
> But if it were to be, it would be non-invasive in the sense that it
> would not cause any backwards compatibility problems.
>
>