SetWindowSize is 1 pixel off sometimes

[GoogleCodeExporter]

Selenium test suite's WindowText.testSetsTheSizeOfTheCurrentWindow reproduces 
this when running on SauceLabs, on Linux (but not on Windows XP), with 
chromedriver 2.16, Chrome 43.0.2357.65

Test code:
https://github.com/SeleniumHQ/selenium/blob/653b63408f0e8f33913c0e27409db8e3c468
0116/java/client/test/org/openqa/selenium/WindowTest.java#L57

Test log:
http://ci.seleniumhq.org:8080/view/Chrome%20Tests/job/Chrome%20Linux%20Java%20Te
sts/3906/consoleText

In the log
https://saucelabs.com/jobs/69971c8fe9644c22ae424bd80db1346e/selenium-server.log
of the SauceLabs' session
https://saucelabs.com/jobs/69971c8fe9644c22ae424bd80db1346e
we can see this:

[2.428][INFO]: COMMAND GetWindowSize {
   "windowHandle": "current"
}
[2.432][INFO]: Waiting for pending navigations...
[2.451][INFO]: Done waiting for pending navigations
[2.489][INFO]: RESPONSE GetWindowSize {
   "height": 739,
   "width": 985
}
[2.547][INFO]: COMMAND SetWindowSize {
   "height": 719,
   "width": 965,
   "windowHandle": "current"
}
[2.660][INFO]: RESPONSE SetWindowSize
[2.719][INFO]: COMMAND GetWindowSize {
   "windowHandle": "current"
}
[2.724][INFO]: RESPONSE GetWindowSize {
   "height": 720,
   "width": 966
}
[3.283][INFO]: COMMAND GetWindowSize {
   "windowHandle": "current"
}
[3.289][INFO]: RESPONSE GetWindowSize {
   "height": 720,
   "width": 966
}
[3.847][INFO]: COMMAND GetWindowSize {
   "windowHandle": "current"
}
[3.851][INFO]: RESPONSE GetWindowSize {
   "height": 720,
   "width": 966
}

... and so on until the test times out waiting and never getting the window 
size 719x965 that it expects.

Video for that session can be found at 
https://assets.saucelabs.com/jobs/69971c8fe9644c22ae424bd80db1346e/video_69971c8
fe9644c22ae424bd80db1346e.flv and it show how window actually changes its size 
in the beginning of the session.

Expected behavior: chromedriver reports window size of 719x965 after 
successfully changing the window size to 719x965 (or whatever the actual pixel 
numbers are).

Note1: that this does not reproduce on Linux in *some* other environments with 
the same chromedriver and Chrome builds. So perhaps this issue is specific to 
some Linux window managers? (I have no idea what SauceLabs is using. Perhaps 
someone could find out and then try to reproduce this issue using a Linux 
system as similar to SauceLabs' as possible?)

On the video it *seems* like the window is initially maximized for some reason. 
Can that be relevant? (I don't think that test explicitly maximizes the window 
before starting other actions, in fact in the selenium/chromedriver log of this 
session we can see that it doesn't)

Note2: This issue didn't reproduce with chromedriver2.12 + Chrome38. Not sure 
if SauceLabs uses a different Linux configuration in that case (unlikely?) or 
if chromedriver or chrome behave differently.

Original issue reported on code.google.com by vlotoshn...@gmail.com on 19 Jun 2015 at 5:19

[GoogleCodeExporter]

selenium continuous build is "red" because of this (and one other, unreported 
but easily findable in logs) issue there.
http://ci.seleniumhq.org:8080/view/Chrome%20Tests/job/Chrome%20Linux%20Java%20Te
sts/

Any hint on ETA on this would be appreciated (so at the very least we could 
silence the test failures if a fix is not coming soon).

Original comment by vlotoshn...@gmail.com on 22 Jun 2015 at 11:24

[GoogleCodeExporter]

We're having trouble reproducing this on our end. The window resizing code in 
ChromeDriver hasn't changed recently, and doesn't do much other than pass the 
requested height+width to Chrome, so this could be a browser-side regression. 
It's probably related to the already-maximized state that the window starts off 
in. Are they running this inside an Xvfb? And do you know what the (possibly 
virtual) screen size is?

It would obviously also be great to know what window manager (and distro) is 
used at Sauce Labs...

Original comment by samu...@chromium.org on 23 Jun 2015 at 4:57

[GoogleCodeExporter]

Also I'm not sure what the ETA would be, given that we don't know what's 
causing it. But it'll be at least a few days in the best case, so I'd suggest 
disabling the test for now.

Original comment by samu...@chromium.org on 23 Jun 2015 at 4:58

[GoogleCodeExporter]

I have tested it with an already-maximized window on Linux- chromedriver 2.16, 
Chrome 43.0.2357.125 and this doesn't cause an off-by-one error

And as Sam mentioned above, it would be helpful to get information about the 
window manager

Original comment by gmanikp...@chromium.org on 23 Jun 2015 at 9:37

• Added labels: Needs-Feedback

[GoogleCodeExporter]

Yep, Thanks guys. I'll be back with some data in a few days. Stay tuned

Original comment by vlotoshn...@gmail.com on 23 Jun 2015 at 10:01

[GoogleCodeExporter]

Guys and gals! Sorry :)

Original comment by vlotoshn...@gmail.com on 23 Jun 2015 at 10:01

[GoogleCodeExporter]

The current setup in Sauce Labs (I'm a Sauce employee) is:
- Ubuntu Linux (12.04.5-server-i386)
- metacity
- xvfb
- x11vnc

The browser is running under the following display:
 $ Xvfb :95 -screen 0 1024x768x24 2>&1 >/dev/null &
 $ x11vnc -rfbauth <passwd> -display :95 -bg -rfbport 5995 -forever -shared
 $ DISPLAY=:95 metacity &

The browser version installed 43.0.2357.65.

Some other interesting findings, the browser seems to be responding incorrectly 
to the graphical environment in ways it doesn't on windows (see screenshots 
attached). This behavior is new to the latest version of chrome.

Original comment by santiycr on 29 Jun 2015 at 3:54

Attachments:

• windows.png
• linux.png

[GoogleCodeExporter]

Oh, I forgot to add both desktops are 1024x768px in case that wasn't as clear 
from the commands used to start the graphical interface 

Original comment by santiycr on 29 Jun 2015 at 3:56

[GoogleCodeExporter]

In case this information can also be of value, Sauce migrated to xvfb back in 
September to workaround a separate issue that manifested itself when running 
under tightvnc (our original setup up until then).

Here are the details of that specific issue which hasn't been addressed either:
Chromedriver bugtracker: 
https://code.google.com/p/chromedriver/issues/detail?id=707#c6
Selenium bugtracker: 
https://code.google.com/p/chromedriver/issues/detail?id=895#c7
Repo with full repro case: 
https://github.com/santiycr/chromedriver-linux-vnc-bug

Again, this isn't about this issue, but it would prevent us to go back to 
tightvnc if that was a preferred setup for the project. We are happy to 
configure our VM the way the project recommends.

Original comment by santiycr on 29 Jun 2015 at 4:06

[GoogleCodeExporter]

I noticed that SetWindowPosition (Position as opposed to Size) is also "1 pixel 
off sometimes" in that environment.

Test testSetsThePositionOfTheCurrentWindow reproduces that.

In 
https://saucelabs.com/jobs/0f61286a455d43c6b634409793afa74d/selenium-server.log 
which is the session that ran that test:
[3.737][INFO]: COMMAND SetWindowPosition {
   "windowHandle": "current",
   "x": 10,
   "y": 10
}
[3.853][INFO]: RESPONSE SetWindowPosition
[3.911][INFO]: COMMAND GetWindowPosition {
   "windowHandle": "current"
}
[3.916][INFO]: RESPONSE GetWindowPosition {
   "x": 9,
   "y": 9
}

Video there 
https://assets.saucelabs.com/jobs/0f61286a455d43c6b634409793afa74d/video_0f61286
a455d43c6b634409793afa74d.flv
also shows that browser window starts seemingly maximized, when we ask to 
resize the window to 200x200 it resizes to something that looks 200x20 instead 
(that's weird and may or may not be related), while staying seemingly 
maximized! (second button of the 3 in the top-right corner of the window looks 
like two crossing squares, not like one larger square).

I'll update in a bit with more data

Original comment by vlotoshn...@gmail.com on 17 Jul 2015 at 2:18

[GoogleCodeExporter]

To add to the last comment,

although the test asks to move the window (top-left corner) to 10x10, and 
although chromedriver (after responding that command with success) reports that 
window position is 9x9, VISUALLY the top-left corner of the window is still at 
0x0 as we can see in the video.

Original comment by vlotoshn...@gmail.com on 17 Jul 2015 at 3:00

[GoogleCodeExporter]

Selenium does not have the Unmaximize command in the protocol.
WebDriver w3c standard now also has the Fullscreen command but not the 
Unfullscreen.
That is intentional, to keep the API lean, unmaximize/unfulscreen can be 
achieved by setting window position and size.

chromedriver/chrome does seem to unmaximize as necessary in most environments, 
including compiz (I wonder if chrome runs any sort of continuous tests with 
multiple windows managers).

I suspect that switching from metacity to compiz, for example, is likely to 
work around this issue. But I am not saying that this is not a bug nor that 
SauceLabs should do that.

Sam, Gauri, do you care to try reproducing this with metacity? Note, this 
didn't reproduce with Chrome 38 (and probably with some later versions), but 
reproduces with chrome 43.

Santi, in #7, what exactly did you mean by "responding incorrectly to the 
graphical environment"? document.width -> undefined? Something else?

One other question, Santi, what does SauceLabs do to make all the Chrome 
windows initially maximized, not just as big as the desktop but maximized? If 
that's some interesting way (such as a metacity setting?), it may be related 
here.

Original comment by vlotoshn...@gmail.com on 17 Jul 2015 at 4:41

[GoogleCodeExporter]

In the logs I noticed

"chromeOptions": { "args": [ "start-maximized", ...

That's probably how Sauce makes it maximized. I wonder what would happen if 
Sauce didn't add that to the args... (tests don't send that over)

Original comment by vlotoshn...@gmail.com on 17 Jul 2015 at 6:43

[GoogleCodeExporter]

Some other browsers (e.g. firefox on linux), I noticed are not started 
maximized on Sauce; for the record.

Original comment by vlotoshn...@gmail.com on 17 Jul 2015 at 6:44

[GoogleCodeExporter]

I ignored the failing tests for now 
https://github.com/SeleniumHQ/selenium/commit/b3e13567fedfc484376be99100172d3049
97454f

Original comment by vlotoshn...@gmail.com on 17 Jul 2015 at 8:00