Provide fallbacks for getWindowRect and setWindowRect

[jonhoo]

These should fall back to individual calls to (get/set)WindowSize + (get/set)WindowPosition if the Rect commands return "unknown command". See the commit that introduces rect to the selenium JS bindings: https://github.com/SeleniumHQ/selenium/commit/6103ef6c923ea43c71779be9a05cc3a6248d1b53

/cc @Phrohdoh

[jonhoo]

See also https://github.com/jonhoo/fantoccini/commit/d2843b0f37bb5deb8b3eb25a4c8a86b99aad7348

[phrohdoh]

AFAICT there are no such commands as the spec only lists SetWindowRect and GetWindowRect.

[jonhoo]

Yeah, the spec only has those, but to be helpful there are a couple of places where we fall back to the original Selenium protocol (this is what the legacy field is for).

[phrohdoh]

Oh I see, I did not understand previously. Sounds easy enough.

[jonhoo]

It looks like there are also some test failures in Chrome on macOS: https://travis-ci.org/jonhoo/fantoccini/jobs/378871411#L873. My guess is that it's related to the window decorations causing an offset in the returned values (see https://github.com/SeleniumHQ/selenium/blob/6103ef6c923ea43c71779be9a05cc3a6248d1b53/javascript/node/selenium-webdriver/test/window_test.js#L125)

[jonhoo]

Sadly these tests also fail when running on a machine with a tiling window manager :(

[stevepryde]

@jonhoo I'm running into this with thirtyfour now. I notice the relevant tests are marked as ignored for now. It seems chromedriver returns only the width and height in this situation, which to my reading goes against the spec. Is this actually a bug in chromedriver on MacOS? I'm happy to raise an issue there given that it's quite easy to reproduce.

I'll probably mask the test failure in thirtyfour for now.

[jonhoo]

Could very well be — I've lost the context on this in the intervening years :sweat_smile: