Skip to content

Document CHROME_EXECUTABLE and friends #2609

Closed

Description

@jonasfj

Searching the code it appears to me that it's possible to override default browser locations using environment variables:

  • CHROME_EXECUTABLE
  • MS_EDGE_EXECUTABLE
  • FIREFOX_EXECUTABLE
  • SAFARI_EXECUTABLE

But from what I can see CHROME_EXECUTABLE the only one documented, and its only documented in the CHANGELOG.md 🤣

I propose that we:

  • Manually attempt to verify that this works.
  • Document it extremely briefly in README.md
  • Document it a bit more thoroughly in doc/configuration.md

I suspect the Configuring Platforms section is a good place to put it, perhaps under the executable key explanation.


IMO, these environment variables are extremely useful when trying to run in a custom CI environment. Where you might not want to hardcode the executable path into dart_test.yaml.

Activity

  1. added
    contributions-welcomeContributions welcome to help resolve this (the resolution is expected to be clear from the issue)
    good first issueA good starting issue for contributors (issues with this label will appear in /contribute)
    type-documentationA request to add or improve documentation
    on Mar 11, 2026
  2. joeccleung commented on Apr 30, 2026

    @joeccleung

    Hello @jonasfj, I have tried setting those environment variables on Mac OS and Windows.

    I used these commands to test:

    • On Mac: FIREFOX_EXECUTABLE=/Users/test_user/Documents/Firefox.app/Contents/MacOS/firefox dart test pkgs/test/test/runner/browser/firefox_test.dart
    • On Windows: $env:FIREFOX_EXECUTABLE='c:\Users\joecc\OneDrive\文件\Mozilla Firefox\firefox.exe'; dart test test/runner/browser/firefox_test.dart

    Here are the results:

    Browser Mac OS Windows 10
    Edge ✅ ✅ [1] [2]
    Firefox ✅ ✅ [1]
    Safari ✅ [3] N/A

    [1]: Windows only. I hit an error when running firefox_test.dart and microsoft_edge_test.dart. In the test "reports an error in onExit", it expects a system error with the wording "Failed to run Firefox: The system cannot find the file specified." (code). However, the actual error message was "Failed to run Firefox: The system cannot find the file specified (at ../../runtime/bin/process_win.cc:577)". I suggest we remove the trailing "." in the assert string to correct the test.

    [2] Using an Edge Dev build.

    [3] Using a Safari Technology Review build.

    I can update the documentation and the unit test to close this issue. Thank you for your attention.

  3. jonasfj commented on Apr 30, 2026

    @jonasfj
    MemberAuthor
  4. Yusufihsangorgel commented on Aug 1, 2026

    @Yusufihsangorgel
    Contributor

    Picking this up if it is still free. @joeccleung, say the word and I will drop it.

    Before writing the docs I went looking for what they would describe, and the behaviour does not match them. ExecutableSettings.merge drops environmentOverride, and customizePlatform merges the defaults with the user's settings, so any settings at all for a browser stop the variable from being read. An executable: key is not required; arguments or headless is enough:

    CHROME_EXECUTABLE=/tmp/FAKE-CHROME
    
    defaults only                      -> /tmp/FAKE-CHROME
    settings: arguments: --disable-gpu -> /Applications/Google Chrome.app/...
    settings: headless: false          -> /Applications/Google Chrome.app/...
    

    That contradicts what 1.23.0 promised ("This overrides any config file settings"), the precedence @jakemac53 and @natebosch settled in #1862, and the ordering the 1.32.0-wip entry applies to DART_TEST_REPORTER. It also takes out the CI case this issue gives as the motivation, since a project that configures anything for Chrome cannot point the runner at another binary.

    Carrying the field through merge restores it. I have that and a regression test in custom_platform_test.dart ready; happy to send the fix and the docs as one PR or keep them separate.

  5. natebosch commented on Aug 6, 2026

    @natebosch
    Member

    happy to send the fix and the docs as one PR or keep them separate.

    I think we can put them both in 1 PR

  6. added a commit that references this issue on Aug 10, 2026
    51463b0
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    contributions-welcomeContributions welcome to help resolve this (the resolution is expected to be clear from the issue)good first issueA good starting issue for contributors (issues with this label will appear in /contribute)package:testtype-documentationA request to add or improve documentation

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions