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...