Re: Window object serialisation

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.

Received on Tuesday, 26 April 2016 15:20:54 UTC