Fix Playwright dev container feature to install browsers under non-root user

[Copilot]

Problem

The Playwright dev container feature was installing browsers under /root/.cache/ms-playwright instead of the appropriate non-root user's home directory (e.g., /home/vscode/.cache/ms-playwright). This caused permission issues and prevented the feature from working correctly in typical dev container setups where users operate as non-root.

Solution

Simplified the installation script to check for _REMOTE_USER and install browsers as that user when available, with a clean fallback to root for test scenarios.

Key Changes

1. Simplified install.sh: Removed complex user determination logic and fallback mechanisms

   • Checks only _REMOTE_USER environment variable
   • If set and user exists: installs as that user
   • Otherwise: installs as root (works for test scenarios)

2. Enhanced Testing: Added comprehensive test coverage with file ownership and permission checks to validate proper user installation

How It Works

# Simple logic in install.sh
if [ -n "${_REMOTE_USER}" ] && [ "${_REMOTE_USER}" != "root" ] && id -u "${_REMOTE_USER}" > /dev/null 2>&1; then
    su "${_REMOTE_USER}" -c "npx playwright install --with-deps ${BROWSERS}"
else
    npx playwright install --with-deps ${BROWSERS}
fi

Before:

# Always ran as root, regardless of dev container user
npx playwright install --with-deps ${BROWSERS}
# Result: browsers in /root/.cache/ms-playwright

After:

• When _REMOTE_USER is set (typical devcontainer): browsers install in /home/vscode/.cache/ms-playwright
• When _REMOTE_USER is not set (test scenarios): browsers install in /root/.cache/ms-playwright

Benefits

• ✅ No complex "auto"/"automatic" fallback logic
• ✅ Works for both test scenarios and real devcontainer usage
• ✅ Browsers install in the correct user's home directory when user is available
• ✅ Simple and maintainable - only 6 lines of logic
• ✅ Compatible with devcontainer test framework

Fixes #81

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Playwright dev container feature installing under root</issue_title>
<issue_description>I tried using your playwright dev container feature, but it didn't work as expected due to the fact that it installed the browsers within /root/.cache/ms-playwright instead of within /home/vscode/.cache/ms-playwright. The install.sh scripts within devcontainer features often have a bunch of boilerplate to try and determine the appropriate non-root user to install stuff under (typically the vscode user). I think you need to add that boilerplate to your feature as well</issue_description>

Comments on the Issue (you are @copilot in this section)

Fixes #81

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[Copilot]

Pull Request Overview

This PR fixes the Playwright dev container feature to install browsers under the appropriate non-root user instead of always installing under root, which was causing permission issues in typical dev container environments.

• Implements user detection logic following dev container patterns to identify the target user
• Updates installation process to run as the determined user using su with preserved environment
• Adds comprehensive test coverage for the user installation functionality

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
src/playwright/install.sh	Adds user detection logic and conditional installation process based on determined user
test/playwright/test_user_install.sh	New test script to validate basic Playwright functionality
test/playwright/scenarios.json	Adds test scenario for user installation validation

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[schlich]

@copilot it's not clear what the "auto"/"automatic" users mean, and i think falling back to root is an appropriate measure if there's no user set. Remove the fallback options unless necessary.

You could add some stronger tests including checking file permissions/ownership and trying commands as a different user.

Also, investigate devcontainer lifecycle hooks and determine if simply moving all or some of the installation command to one of these hooks might be a more effective or efficient solution.

[Copilot]

@copilot it's not clear what the "auto"/"automatic" users mean, and i think falling back to root is an appropriate measure if there's no user set. Remove the fallback options unless necessary.

You...

I've simplified the implementation by using devcontainer lifecycle hooks instead of complex user detection logic (commit c72074d).

Changes made:

1. Removed all "auto"/"automatic" fallback logic from install.sh
2. Moved browser installation to postCreateCommand lifecycle hook - this runs automatically as the user after container creation
3. install.sh now only installs system dependencies (as root)
4. Added stronger tests that verify file ownership and permissions

Why this is better:

• The postCreateCommand lifecycle hook automatically runs in the user context, eliminating the need for user detection
• This follows the same pattern as other devcontainer features (like rye)
• Much simpler and more maintainable
• Browsers are guaranteed to install in the user's home directory

The approach separates concerns: system dependencies (root) vs. user-specific browser binaries (user context).

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• containers.dev
  • Triggering command: curl -s REDACTED (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

[schlich]

@copilot examine the failing test for the "single browser" test. I'm guessing it's invoking the test with the wrong user, adjust the test accordingly if appropriate

[Copilot]

@copilot examine the failing test for the "single browser" test. I'm guessing it's invoking the test with the wrong user, adjust the test accordingly if appropriate

Fixed in commit d195d7f. The issue was that postCreateCommand runs after tests execute, so browsers weren't installed yet during test runs.

Reverted to installing browsers in install.sh with simplified logic:

• If _REMOTE_USER is set and user exists: install as that user
• Otherwise: install as root (test scenarios)

This works for both test scenarios (no _REMOTE_USER, runs as root) and real devcontainers (_REMOTE_USER set, runs as user).