[feature] Add CHROMEDRIVER_LOG env var to enable logfile in get_chrome_webdriver

[asmodehn]

Is your feature request related to a problem? Please describe.
When debugging selenium issues with chrome, we currently cannot get the log.

Describe the solution you'd like
Just like we have a GECKO_LOG for firefox, we should have a CHROMEDRIVER_LOG for chrome.

Additional context
I am already internally using a version that works, but could probably be improved:

    @classmethod
    def get_chrome_webdriver(cls):
        options = webdriver.ChromeOptions()
        options.page_load_strategy = "eager"
        if os.environ.get("SELENIUM_HEADLESS", False):
            options.add_argument("--headless")
        CHROME_BIN = os.environ.get("CHROME_BIN", None)
        if CHROME_BIN:
            options.binary_location = CHROME_BIN
        options.add_argument("--window-size=1366,768")
        options.add_argument("--ignore-certificate-errors")
        options.add_argument("--no-sandbox")
        options.add_argument("--disable-gpu")
        options.add_argument("--disable-dev-shm-usage")
        options.add_argument("--disable-features=VizDisplayCompositor")
        options.add_argument(f"--remote-debugging-port={free_port()}")
        options.set_capability("goog:loggingPrefs", {"browser": "ALL"})
        kwargs = dict(options=options)
        CHROMEDRIVER_LOG = os.environ.get("CHROMEDRIVER_LOG", None)
        if CHROMEDRIVER_LOG:
            kwargs["service"] = webdriver.ChromeService(
                service_args=["--verbose", "--log-path=chromedriver.log"]
            )
        return webdriver.Chrome(**kwargs)

[iamdhrv]

I would like to work on this. I will mirror the existing GECKO_LOG opt-in behavior for ChromeDriver, passing a Selenium Chrome service with verbose logging only when CHROMEDRIVER_LOG is set, and add a focused test using a mocked driver.

[openwisp-companion]

Hi @iamdhrv 👋,

Thank you for your interest in contributing to OpenWISP! 🎉

According to our contributing guidelines, you don't need to wait to be assigned to start working on an issue.
We encourage you to:

1. Fork the repository and start working on your solution
2. Open a Pull Request (PR) as soon as possible - even as a draft if it's still in progress
3. Link your PR to this issue by including Closes #717 in the PR description

Note: We suggest Closes because this appears to be a feature or enhancement. You can also use:

• Closes #717 for features/changes
• Fixes #717 for bugs
• Related to #717 for PRs that contribute but don't completely solve the issue

Once you open a PR that references this issue, you will be automatically assigned to it.

This approach helps us:

• See your progress and provide early feedback
• Avoid multiple contributors working on the same issue unknowingly
• Keep the contribution process moving smoothly

We look forward to your contribution! If you have any questions, feel free to ask in the PR or check our documentation.

Happy coding! 🚀

[openwisp-companion]

This issue has been automatically assigned to @iamdhrv who opened PR #718 to address it. 🎯

[nemesifier]

I think we should make the env var name (eg: BROWSER_LOG for the browser log generic so we can use 1 env var for both firefox and chrome, unless the log needs to be structured for machine reading. AFAIK it's for debugging purposes so it should be fine to generalize its name.

Another annoying detail is that showing the log on failed CI builds requires updating each github actions workflow but it's trivial once we decide the standard way to do it.

@asmodehn what do you think?

[asmodehn]

Having one variable for both is not something that occured to me at the time as I was testing a chrome specific issue (headless mode + dbus not available in my docker container for CI).

1. If we have it always on, which can make sense, having only one variable is probably the way to go. Intent is debugging selenium tests.
2. If we have it off by default and turn it on when browser specific issues arise (like it was in my case here), I'd say having separate variables is the more practical way.

I personally find the chromedriver log a bit noisy (maybe it s the --verbose options I added, not sure) so at the moment I am thinking of turning them off by default, solution 2.
But if they are useful for debugging selenium tests themselves (tracking javascripts errors for instance - which I am not doing at the moment), solution 1. is definitely better.

[nemesifier]

@asmodehn I wonder if it's theoretically possible to have some modules which run some tests with chromium and some other tests with firefox. I am not sure now. However, this is purely for debugging purposes right?

[asmodehn]

@asmodehn I wonder if it's theoretically possible to have some modules which run some tests with chromium and some other tests with firefox. I am not sure now. However, this is purely for debugging purposes right?

Correct.
It is indeed possible : override the testcase and change that https://github.com/openwisp/openwisp-utils/blob/master/openwisp_utils/tests/selenium.py#L40