Edge DevTools Extension Fails to Launch Visible Browser and DevTools in VS Code on Windows 11

[jircdev]

Environment (please complete the following information):

• OS: Windows 11
• Extension version: 2.1.5
• Browser: Microsoft Edge Version 124.0.2478.67

Describe the bug:
The Microsoft Edge Tools for VS Code does not function as expected. The browser is supposed to open within VS Code tabs for debugging, but it doesn't launch visibly and seems to be stuck in headless mode despite settings indicating otherwise. The DevTools panel does not open, and the extension throws an error stating "Error while fetching list of available targets No available targets to attach."

Repro steps:

1. Ensure Microsoft Edge is installed and updated.
2. Install Microsoft Edge Tools for VS Code extension version 2.1.5.
3. Attempt to configure launch.json with both default and documentation-specified parameters to launch Edge.
4. Attempt to launch the Edge browser through the VS Code extension using the configuration.
5. Try right-clicking an HTML file and selecting "Open with Edge" as described in the Microsoft documentation.
6. Observe that neither method results in the expected behavior, and the browser does not visibly open; extension errors with no available targets.

Expected behavior:
The expected behavior is for Microsoft Edge to open in a visible tab within VS Code, allowing for interaction with the DevTools directly within the IDE environment.

Additional context:
The issue persists even after ensuring all settings for headless mode are disabled and after multiple restarts of both Edge and VS Code. Screenshots of the error messages and settings have been provided to illustrate the problem. Multiple methods documented for opening the browser and DevTools directly have failed to function as described.

AB#50580089

[captainbrosset]

Thanks for filing. Adding this to our backlog.

[carloswm85]

@jircdev can you share your launch.json and tasks.json files? I was having the same Error as you, and some changes to the default files configurations seems to have fixed it. As you can see in this gif, the error surges when the browser is launched BEFORE the compilation is finished.