Add setting to open non-localhost links in Integrated Browser

[Copilot]

This change adds a dedicated setting to route non-localhost HTTP(S) links into the Integrated Browser, complementing the existing localhost-only behavior. Link routing now selects the appropriate setting based on URL authority instead of hardcoding localhost checks in the opener contribution.

• Configuration

  • Added workbench.browser.openExternalLinks to open non-localhost HTTP(S) links in the Integrated Browser.
  • Kept existing workbench.browser.openLocalhostLinks semantics unchanged for localhost/all-interfaces targets.

• Link opener behavior

  • Extracted URL classification into browserLinkOpeners.ts so opener decisions are centralized.
  • Updated opener contribution to:
    • choose setting by URL class (localhost/all-interfaces vs external),
    • preserve default-setting hint behavior using the selected setting key,
    • emit distinct telemetry source (externalLinkOpener vs localhostLinkOpener).

• Structure and naming

  • Renamed contribution to BrowserLinkOpenerContribution with ID workbench.contrib.browserLinkOpener to reflect expanded scope.

• Targeted coverage

  • Added focused unit tests for URL classification and setting selection behavior.

const openerSetting = getIntegratedBrowserLinkOpenerSetting(
	href,
	config.getValue<boolean>('workbench.browser.openLocalhostLinks'),
	config.getValue<boolean>('workbench.browser.openExternalLinks')
);

[jruales]

@copilot resolve the merge conflicts in this pull request

[jruales]

@copilot also update the PR description to reflect the latest changes

[Copilot]

Pull request overview

This PR adds configurable Integrated Browser routing for non-localhost HTTP(S) links, alongside the existing localhost/all-interfaces behavior.

Changes:

• Adds workbench.browser.openExternalLinks.
• Extracts URL-to-setting classification into a shared helper with tests.
• Updates opener telemetry/source naming for external-link opens.

Show a summary per file

File	Description
src/vs/workbench/contrib/browserView/common/browserLinkOpeners.ts	Adds helper for classifying HTTP(S) links to the relevant opener setting.
src/vs/workbench/contrib/browserView/test/common/browserLinkOpeners.test.ts	Adds unit coverage for localhost, external, and invalid/non-HTTP(S) links.
src/vs/workbench/contrib/browserView/electron-browser/features/browserTabManagementFeatures.ts	Uses the helper in the opener contribution and registers the new setting.
src/vs/platform/browserView/common/browserViewTelemetry.ts	Adds telemetry source for external-link opener usage.

Copilot's findings

• Files reviewed: 4/4 changed files
• Comments generated: 2

[Copilot]

@copilot resolve the merge conflicts in this pull request

Resolved in ae2dcdc7: merged origin/main into this branch and fixed the conflict in browserTabManagementFeatures.ts while preserving the PR’s integrated-browser link opener behavior.

[Copilot]

@copilot also update the PR description to reflect the latest changes

Updated the PR description to reflect the latest state of the branch, including the setting-key classification refactor, caller-side config lookup, and the merge-resolution result in ae2dcdc7.

[kycutler]

I think I'd prefer to have a list of rules for which links to open or not -- some things like GitHub might stay better in the browser while e.g docs should be opened in VS Code. I'm thinking something like gitignore syntax but for URLs, or a list of items with a pattern and dropdown for whether it should be opened internally or externally.

[kycutler]

It seems weird to get the configuration key in a helper, but then test the actual value here? Might make more sense to have a shouldOpenInIntegratedBrowser helper that just takes the URL and config service. I also question the value of having a whole new file for this one helper that is only used here.