clj-commons / etaoin

Pure Clojure Webdriver protocol implementation

Home Page:https://cljdoc.org/d/etaoin

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

docs: keyboard chords example might be macos specific

lread opened this issue · comments

In the user guide, under keyboard chords there is an example:

The main input gets populated with "CAPS IS GREAT". Now maybe you’d like to delete the last word. Assuming you are using Chrome, this is done by pressing backspace holding Alt. Let’s do that:

(e/fill-active driver (k/with-alt k/backspace))
(e/get-element-value driver :active)
;; => "CAPS IS "

I think the alt-backspace key combo might be macOS-specific.
I've recently switched from macOS to Linux and when run through test-doc-blocks, this example fails.

This is probably why I configured CI to run bb test-doc only on macOS.

A bit of a rabbit hole, I have gone down.

Since test-doc is no longer macOS specific, I figured why not add Linux and Windows to the test-doc CI matrix.

The Linux tests seem to pass fine locally on my Linux dev box, but when I repeated them locally from a docker image created from our DockerFile, I had failures.

Our DockerFile runs everything from a root user.
This is not recommended for WebDriver and can cause issues.

I don't expect issues on GitHub Actions, it runs steps under a non-root user. But for local testing of test-doc, fixing our DockerFile to use a non-root user is necessary.

Our user guide examples (rightly) assume you are not running from a root user and do not add hacks to make this root user work (--no-sandbox args for Chrome for example).

So I figured why not just have our docker image use non-root user?
Well, this can be done, but permission mapping for non-root docker users to mounted volumes is not something that works easily without modifying the host system.

And I am having mysteries with Chrome.

I'll poke around a bit more...

So I had a look at what Selenium does for their Chrome docker image.

They do use a non-root user which is what I think we want.
But they also wrap the chrome browser launcher, to include the --no-sandbox option.
So the advice from some is to not use --no-sandbox, but maybe it is needed for docker images?

Hmmm... so adding --no-sandbox to the Selenium docker image happened almost 9 years ago!

I guess I should probably go with the flow here...