Investigate X11 forwarding as opposed to VNC about docker-selenium HOT 8 CLOSED

How about we just expose the X server domain socket in a volume like this:

http://stackoverflow.com/a/25168483

from docker-selenium.

It grants the container full access to the xserver on the host

from docker-selenium.

Just to clarify, is the current usage of xvfb incompatible with the approach of mounting the host's X socket in, say, a StandaloneChrome container?

from docker-selenium.

Correct me if I'm wrong, but I believe the answer to ^ is "yes". xvfb sets up it's own X server, which is diametrically opposed to passing the socket from the host's X server in. Unwrapping the java ... -jar /opt/selenium/selenium-server-standalone.jar from xvfb-run, and passing DISPLAY/mounting /tmp/.X11-unix at docker run time works as desired.

Would an option to bypass the xvfb-run segment of each entrypoint be an acceptable solution? Something conceptually like:

if [ ! -z "$NO_XVFB" ]; then
  java ${JAVA_OPTS} -jar /opt/selenium/selenium-server-standalone.jar \
    ${SE_OPTS} &
else
  xvfb-run -n $SERVERNUM --server-args="-screen 0 $GEOMETRY -ac +extension RANDR" \
    java ${JAVA_OPTS} -jar /opt/selenium/selenium-server-standalone.jar \
    ${SE_OPTS} &
fi

from docker-selenium.

I agree is now incompatible as of now.

I confirmed the x11 redirect works ~1yr ago on version v2.46.0-x11 while playing with Xephyr to redirect X to the docker host and passing -v /tmp/.X11-unix/X${XE_DISP_NUM}:/tmp/.X11-unix/X${XE_DISP_NUM} among other things.

But drop it after because didn't really want to support this use case back then but if someone wants to implement it for real and become officially supported that might help.

from docker-selenium.

Pushed #346 and looking for feedback.

from docker-selenium.

Hi all,

Is this still relevant? This issue and the PR have been stale for ~1.5 years.

from docker-selenium.

Closing issue since it is completely stale (also the related PR).

from docker-selenium.