JSON serialization of the WindowProxy object isn't very useful if it's a nested browser context

[gsnedders]

If the WindowProxy is a nested browsing context, you get a window handle, except you can't actually use it for anything (e.g., you can't use it to switch the current browsing context). Having an opaque string that's only useful for comparing it doesn't seem like it is very useful?

(Technically, you could, by going to its top-level browsing context and then switching to every frame until you find one with the same window handle.)

As for a use-case: I have a message event and I want to switch the current browsing context to e.source to react to that message.

[andreastt]

Perhaps there should be a separate serialisation for frames, similar to that for windows and elements. That would highlight what it could be used for, since handles for top-level- and nested- browsing contexts are not interchangeable.

Regarding the use case: It would be nice if the WebDriver API didn’t distinguish between windows and frames, so that one reference could be used for switching to any browsing context, anywhere. This would make it possible to take the serialised return value of ExecuteScript("return MessageEvent.source") and switch to whatever WindowProxy.

With the current semantics you need to first figure out what kind of window source is before you can do anything. Is it another OS window? Is it a parent document? Another frame?

Other ideas?

[gsnedders]

Well the JSON serialisation already distinguishes between windows and frames (because they get put under different keys), so you already know which WebDriver API you'd have to call if switch to frame could take that opaque string.