Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[🐛 Bug]: Setting lang attribute doesn't apply to the test containers #1750

Closed
jsa34 opened this issue Dec 19, 2022 · 4 comments · Fixed by #1751 or #1778
Closed

[🐛 Bug]: Setting lang attribute doesn't apply to the test containers #1750

jsa34 opened this issue Dec 19, 2022 · 4 comments · Fixed by #1751 or #1778

Comments

@jsa34
Copy link
Contributor

jsa34 commented Dec 19, 2022

What happened?

When trying to run with a different locale, trying all possible ways to set this via the chromedriver doesn't seem to work.

Apparently there is an issue with setting this, and needs to be done at the env variable level. This was previously identified:
elgalu/docker-selenium#159

And I am still seeing the same behaviour in the current docker selenium images.

Command used to start Selenium Grid with Docker

Using dynamic grid as documented on README.md

Relevant log output

N/A

However, no matter what I set, the browser always is set to en_US and en as the languages in the settings section of the browser when inspecting.

Operating System

Centos 9

Docker Selenium version (tag)

4.5.0

@jsa34
Copy link
Contributor Author

jsa34 commented Jan 24, 2023

Looks like this still doesn't work....

ChromeOptions set:

        ChromeOptions chromeOptions = getBaseChromeOptions();
        Map<String, Object> prefs = new HashMap<>();
        chromeOptions.addArguments("--no-sandbox");
        chromeOptions.addArguments("--verbose");
        chromeOptions.addArguments("--disable-dev-shm-usage");
        chromeOptions.addArguments("--safebrowsing-disable-download-protection");
        **chromeOptions.addArguments("--lang=en-GB");**
        chromeOptions.setCapability(CapabilityType.ACCEPT_INSECURE_CERTS, true);
        prefs.put("safebrowsing.enabled", "true");
        chromeOptions.setExperimentalOption("prefs", prefs);
        return chromeOptions;

And the lang attribute is send in the prefs when node container is created:

11:31:26.430 INFO [LocalDistributor.newSession] - Session request received by the Distributor:
 [Capabilities {acceptInsecureCerts: true, browserName: chrome, bstack:options: {buildName: Automation 24-01-2023, projectName: utomation}, goog:chromeOptions: {args: [--no-sandbox, --verbose, --disable-dev-shm-usage, --safebrowsing-disable-down..., --lang=en-GB], extensions: [], prefs: {safebrowsing.enabled: true}}, se:recordVideo: false, se:screenResolution: 1920x1080, se:timeZone: Europe/London}]

I wanted to check before I submit a new PR. Should I set the env variable in the wrapper script instead of outside? It looks like it's setting the LANGUAGE env variable but in the "default" node container, not the dynamically generated actual node containers for test runs?

I can see when starting a bash session inside the test container, the env variable of "LANGUAGE" is still set to en-US:

seluser@container:/$ echo $LANGUAGE
en_US.UTF-8

Perhaps we should set the env variable in the script passed to the container to start the chrome executable?

@jsa34
Copy link
Contributor Author

jsa34 commented Jan 24, 2023

Something like:

#!/bin/bash

WRAPPER_PATH=$(readlink -f /usr/bin/microsoft-edge)
BASE_PATH="$WRAPPER_PATH-base"
mv "$WRAPPER_PATH" "$BASE_PATH"

# Debian/Ubuntu seems to not respect --lang, it instead needs to be a LANGUAGE environment var
# See: https://stackoverflow.com/a/41893197/359999
for var in "$@"; do
   if [[ $var == --lang=* ]]; then
      LANGUAGE=${var//--lang=}
   fi
done

cat > "$WRAPPER_PATH" <<_EOF
#!/bin/bash

# umask 002 ensures default permissions of files are 664 (rw-rw-r--) and directories are 775 (rwxrwxr-x).
umask 002

# Set language environment variable
export LANGUAGE="$LANGUAGE"

# Note: exec -a below is a bashism.
exec -a "\$0" "$BASE_PATH" --no-sandbox "\$@"
_EOF
chmod +x "$WRAPPER_PATH"

@jsa34
Copy link
Contributor Author

jsa34 commented Jan 24, 2023

(@diemol I can't reopen this issue)

Copy link

github-actions bot commented Dec 9, 2023

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked and limited conversation to collaborators Dec 9, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
2 participants