Add Windows browser path checks to Chromium detection#1014
Add Windows browser path checks to Chromium detection#1014ryanhoangt merged 41 commits intoOpenHands:mainfrom
Conversation
Enhanced _check_chromium_available to check common Windows installation paths for Chrome and Edge executables. Also added support for Playwright cache detection on Windows using LOCALAPPDATA.
|
[Automatic Post]: I have assigned @simonrosenberg as a reviewer based on git blame information. Thanks in advance for the help! |
enyst
left a comment
There was a problem hiding this comment.
Thank you for your contributions to Windows compatibility!
I'm not sure this the way we need to go on this... I think if branches in various tools or other code on this issue are error-prone, destined to become many, reduce visibility of other code thus maintainability.
I do understand that in the browser tool case it seems hard to avoid... but then that's always the case. Idk, I'd love to give it some thought. One small question: could we at least, if we are going to do special cases throughout the codebase, make sure to recognize them in exactly the same conditions?
IMHO though, we'll be happier in time if we don't do special cases throughout the codebase...
Removed redundant os.name check and always define Windows Chromium and Edge paths. Simplified Playwright cache candidate logic by unconditionally including the Windows path.
enyst
left a comment
There was a problem hiding this comment.
Thank you, I see... I guess that's just how this one goes, we have Linux paths, Mac paths, Windows paths... 🤔
I kinda liked this one too, in another PR... it's an if (unfortunately 😅), but it's in __init__.py, and it makes sure to expose exactly the necessary classes

The separation of the implementation in WindowsTerminal is great IMHO. It's the ideal, if we could keep it that way.
One reason, it seems to me, is that usually, not always but usually, it's not the same people working with one or the other. It matters, IMHO, for a developer reading the code, to be able to focus on code relevant to their work. It helps maintainability, ease of debugging, code understanding.
While I'm not fully sure yet how the end solution looks on the whole issue, IMHO separated code is better than hybrid, regarding Windows (generally speaking, not in this PR). In other places, like this, I really appreciate when these pieces are at least very clear.
Thank you, I see there's no super obvious solution here, the code asks for system-specific paths, and it's the case for Linux and Mac too.
|
@enyst would you approve that PR? |
Simplifies and generalizes the construction of Windows browser executable paths by iterating over environment variables and browser definitions. This reduces code duplication and improves maintainability.
Cleaned up unnecessary trailing whitespace in the _check_chromium_available function for improved code style.
Remove incorrect skip logic that prevented checking %LOCALAPPDATA% for Microsoft Edge installations. While Edge is typically installed system-wide, it can also be installed per-user in enterprise environments at %LOCALAPPDATA%\Microsoft\Edge\Application\msedge.exe. This fix ensures the browser detection can find Edge in both installation scenarios.
| ] | ||
| browsers = [ | ||
| ("Google", "Chrome", "Application", "chrome.exe"), | ||
| ("Microsoft", "Edge", "Application", "msedge.exe"), |
There was a problem hiding this comment.
Actually, why do we need browsers on Windows, doesn't the browser tool work with playwright?
There was a problem hiding this comment.
To use existing browsers instead of installing browsers using playwright (uvx playwright install chromium)
There was a problem hiding this comment.
I see, thank you.
Tiny nit: could we call them windows_browsers?
Is LOCALAPPDATA a common env var used on Windows? Is it set by default?
There was a problem hiding this comment.
Is LOCALAPPDATA a common env var used on Windows? Is it set by default?
Yes. Source: https://devblogs.microsoft.com/oldnewthing/20231212-00/?p=109137
There was a problem hiding this comment.
For discussion here, #1210 (comment)
WDYT about we can inherit this tool, create a new Windows Browser tool, and add windows specific handling there?
There was a problem hiding this comment.
That sounds great! It seems we have more code coming. And thanks to inheritance, we can reuse a bunch of code anyway.
There was a problem hiding this comment.
@SmartManoj are you ok w/ implementing this? 👀
enyst
left a comment
There was a problem hiding this comment.
Could you please add a screenshot or logs, that show if the browser tool is working?
I also added a small question inline, sorry, I don't understand, does it work on chrome or edge?
|
Without this PR, |
script checks for chrome first and then edge and then chrome in playwright dir. |
|
Sorry I'm a bit dense, so if it finds Edge, does agent-sdk work with the browser tool on Windows? |
It will as edge is based on chromium. Browser-use test. Edge opened and navigated to the URL.
|
|
@SmartManoj I see in your screenshot that browser-use seems to navigate to the page. We know we have adapted browser-use for the browser tool in agent-sdk. So I would guess the tool works, but I don't know. For example, this is supposed to be able to take screenshots: Is it... able to take screenshots? 😅 What I mean by my question is, does agent-sdk with browser tool work on Windows after this PR, or is there more to do for it to work? Is there some way we could see it work? |
BrowserToolExecutor now checks common Linux and macOS installation paths for Chromium and Chrome if not found in PATH. Corresponding tests were added to verify detection via these standard paths.
Renamed the example script for consistency or to reflect updated numbering in the standalone SDK examples directory.
Adds a print statement to display the accumulated cost from the LLM metrics at the end of the Tom agent consultation example.
Changed references from 30_windows.py to 31_windows.py in the exemption list and workflow configuration to reflect the new filename.
ryanhoangt
left a comment
There was a problem hiding this comment.
Thank you, this LGTM. I added a new example script (31_windows) for e2e testing without terminal tool. I also tested it on a Windows machine and via test-examples label and they seem to run without issues. Would love final 👀 from @xingyaoww and @enyst regarding the Windows code separation.
There was a problem hiding this comment.
Shall we rename this to "windows_browsing_support"
There was a problem hiding this comment.
@OpenHands please rename to 31_windows_browsing.py
There was a problem hiding this comment.
I'm on it! xingyaoww can track my progress at all-hands.dev
There was a problem hiding this comment.
actually i don't think we need this example? shouldn't examples/01_standalone_sdk/15_browser_use.py do the same thing? maybe we should remove it
There was a problem hiding this comment.
Summary
I've successfully completed the file rename as requested in PR #1014. Here's what was done:
Changes Made:
-
Renamed the example file:
examples/01_standalone_sdk/31_windows.py→examples/01_standalone_sdk/31_windows_browsing.pyusinggit mvto preserve the file history -
Updated all references to the old filename in:
.github/scripts/check_documented_examples.py- Updated the EXEMPT_EXAMPLES set.github/workflows/run-examples.yml- Updated both test filters (exclusion filter and Windows-specific test filter)
Verification:
- ✅ All references confirmed updated
- ✅ Pre-commit hooks passed (YAML format, Ruff format & lint, pycodestyle, pyright, import dependency rules, tool registration check)
- ✅ Changes committed with proper co-authorship attribution
- ✅ Changes pushed to the fork's
chromiumbranch
The PR #1014 has been updated with commit 058dc504 which includes the file rename and all necessary reference updates.
There was a problem hiding this comment.
I'm on it! xingyaoww can track my progress at all-hands.dev
There was a problem hiding this comment.
Summary
I've successfully removed the 31_windows_browsing.py example from PR #1014 as requested. The changes have been committed and pushed to update the pull request.
Changes Made:
✅ Removed the example file:
examples/01_standalone_sdk/31_windows_browsing.py
✅ Updated CI workflow (.github/workflows/run-examples.yml):
- Removed the entire
test-examples-windowsjob (which was created specifically for this example) - Removed the dependency on
test-examples-windowsfrom the maintest-examplesjob - Removed the step that downloads Windows example results
- Removed the pytest exclusion filter
-k "not 31_windows_browsing.py" - Removed the step that copies Windows example results to the main job
✅ Updated documentation check script (.github/scripts/check_documented_examples.py):
- Cleared the
EXEMPT_EXAMPLESset (removed the 31_windows_browsing.py entry)
All pre-commit hooks passed successfully (YAML format, Ruff format/lint, pycodestyle, pyright, dependency checks, and tool registration checks).
Commit: 8131ee23
The PR has been updated and is ready for review. The example was redundant since 15_browser_use.py already demonstrates browser functionality.
There was a problem hiding this comment.
actually i don't think we need this example? shouldn't examples/01_standalone_sdk/15_browser_use.py do the same thing? maybe we should remove it
@xingyaoww this example removed the terminal tool from 15_browser_use.py, since it won't work right now. Also I made this test run only on Windows runner and we also need some custom UTF-8 handling, which isn't required on Linux runner. I think we should keep it for now, and after #1012 we can remove it and use 15_browser_use for both. WDYT?
There was a problem hiding this comment.
hmm, can we convert this to a test rather than an example here? I feel putting this as an example could be quite confusing (especially we want to remove them later).
Updated references in workflow and script files to reflect the new filename. Co-authored-by: openhands <openhands@all-hands.dev>
As discussed in PR comments, this example is redundant since examples/01_standalone_sdk/15_browser_use.py already demonstrates browser functionality. Changes: - Remove examples/01_standalone_sdk/31_windows_browsing.py - Remove test-examples-windows job from CI workflow - Remove Windows example exclusions and result handling from CI - Clear EXEMPT_EXAMPLES set in check_documented_examples.py Co-authored-by: openhands <openhands@all-hands.dev>
Co-authored-by: Engel Nyst <engel.nyst@gmail.com>
Renamed test methods to use 'testcheck_chromium_available_*' and updated calls from '_check_chromium_available' to 'check_chromium_available' to reflect changes in the BrowserToolExecutor API.


Enhanced
_check_chromium_availableto check common Windows installation paths for Chrome and Edge executables. Also added support for Playwright cache detection on Windows using LOCALAPPDATA.