node-chrome with --headless rather than XVFB

[graingert]

Run node-chrome with --headless rather than XVFB, to reduce resource usage.

[graingert]

Users don't browse in xvfb, what's your point?

[ddavison]

no, users use the physical browser. Xvfb allows the rendering of said physical browsers.

[graingert]

Are you suggesting that chrome --headless behaves differently from chrome under xvfb?

…

On 12 Apr 2017 02:29, "Dj" ***@***.***> wrote: no, users use the physical browser. Xvfb allows the rendering of said physical browsers. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#429 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAZQTMWyJFMfal-UsVak1INjMBFNCeS7ks5rvCkKgaJpZM4MusZ3> .

[SpencerMalone]

PhantomJS' solo maintainer is leaving because of headless chrome. Can we reopen this discussion? (source: https://groups.google.com/forum/#!topic/phantomjs/9aI5d-LDuNE)

[ddavison]

i guess i'm not familiar with chrome's headless mode.. tell me more, @graingert

[graingert]

@ddavison you run chrome --headless and it manages its own internal framebuffer, rather than needing X11

It should massively simplify the default node-chrome.

Also it's got a VNC like protocol over the chrome debug socket, so you wouldn't need node-chrome-debug either

[ddavison]

I think the biggest benefit that users find with the debug, is that you can VNC into it. You're saying that this could be eliminated? If that's the case, ok then. sign me up - apologies for the abrupt closing. An issue file with a very small description is dangerous as it leaves everything up to speculation :)

I wasn't familiar with chrome --headless (hence why i asked you to elaborate)

If this is possible, then yes.. we'll go this route. I'll keep this issue open and i'll mark as investigating.

[madhavajay]

I think most automated testing will use chrome headless going forwards, and using docker for automated testing is a perfect fit, so this just seems like an obvious thing, in fact, iv been asking about it for the last few months and even tried to roll my own but chrome --headless was buggy. Big +1 from me on this as PhantomJS 2.5 release isn't even available and maybe we won't see it now that the maintainer has stepped down.

The main reason is quite simple.... Chrome uses a lot of memory and cpu and that should be lower without Xvfb and real rendering.

[SpencerMalone]

So, I just put in some time into this. XVFB will still be required for almost all projects, sadly (unless someone finds a workaround)

In general it wasn't too rough to get running, but I get thrown the following when I try to use it for tests that have keyCode interactions (aka, any sendkeys stuff):

unknown error: an X display is required for keycode conversions, consider using Xvfb
        (Session info: content shell=)
        (Driver info: chromedriver=2.29.461571 (8a88bbe0775e2a23afda0ceaf2ef7ee74e822cc5),platform=Linux 4.9.4-moby x86_64) (WARNING: The server did not provide any stacktrace information)
      Command duration or timeout: 26 milliseconds
      Build info: version: '2.52.0', revision: '4c2593c', time: '2016-02-11 19:06:42'
      System info: host: '1d5acd9906ce', ip: '172.17.0.4', os.name: 'Linux', os.arch: 'amd64', os.version: '4.9.4-moby', java.version: '1.8.0_121'
      Driver info: org.openqa.selenium.chrome.ChromeDriver

EDIT: Throwing XVFB in and using that to run the SE process (like normal), it all works properly, I'm just not sure that we're gaining much if we do that.

I haven't poked around with this repo in ages. Do y'all have a standardish way of measuring performance?

[SpencerMalone]

I guess the XVFB thing is a chromedriver requirement, so I opened a ticket here: https://bugs.chromium.org/p/chromedriver/issues/detail?id=1772

If you wanna reproduce / help out with finding a fix, you can find steps to make an easy one-off container that runs selenium locally (without a hub/node configuration) in that issue. It's easy enough to convert those steps into the docker-selenium containers, but the send key stuff still exists.

[elgalu]

Indeed, I managed even to set the Chrome browser window size but once I removed Xvfb from docker-selenium I was also bitten by @SpencerMalone error:

Failed: unknown error: an X display is required for keycode conversions, consider using Xvfb
  (Session info: headless chrome=58.0.3029.81)
  (Driver info: chromedriver=2.29.461571 (8a88bbe0775e2a23afda0ceaf2ef7ee74e822cc5),platform=Linux 4.4.0-72-generic x86_64) (WARNING: The server did not provide any stacktrace information)
Command duration or timeout: 22 milliseconds
Build info: version: '3.3.1', revision: '5234b32', time: '2017-03-10 09:04:52 -0800'
System info: host: 'ccd8e5f77172', ip: '172.17.0.2', os.name: 'Linux', os.arch: 'amd64', os.version: '4.4.0-72-generic', java.version: '1.8.0_121'
Driver info: org.openqa.selenium.chrome.ChromeDriver
Capabilities [{applicationCacheEnabled=false, rotatable=false, mobileEmulationEnabled=false, networkConnectionEnabled=false, chrome={chromedriverVersion=2.29.461571 (8a88bbe0775e2a23afda0ceaf2ef7ee74e822cc5), userDataDir=/tmp/.org.chromium.Chromium.u1tWQG}, takesHeapSnapshot=true, pageLoadStrategy=normal, databaseEnabled=false, handlesAlerts=true, hasTouchScreen=false, version=58.0.3029.81, platform=LINUX, browserConnectionEnabled=false, nativeEvents=true, acceptSslCerts=true, locationContextEnabled=true, webStorageEnabled=true, browserName=chrome, takesScreenshot=true, javascriptEnabled=true, cssSelectorsEnabled=true, unexpectedAlertBehaviour=}]
Session ID: a7bc6bb38644f13e7a9c9b2c33fbcd61