Use case
Different projects may belong to different contexts/accounts.
Example:
- Work project → Microsoft Edge
- Personal/hobby project → Google Chrome
The browser preference belongs to the BuildMonitor project, not globally and not to the Azure connection.
Two projects using the same Azure DevOps connection may intentionally use different browsers.
Proposed Settings UX
Per project:
Open links with:
- System default
- installed browser A
- installed browser B
- etc.
On Windows, discover installed browsers where practical rather than hard-coding only Chrome/Edge.
System default must always be available.
Do not store credentials/profile secrets.
A custom executable/path option can be investigated but is not required for v1.
Scope of preference
The selected project browser should consistently apply to links opened on behalf of that project, including where applicable:
- Azure Status
- Azure Run #
- Azure Build No.
- Azure PR #
- Azure Branch
- Site ready / Open site
- other project-specific web navigation
Audit existing project-originated Process.Start/browser-launch paths when implementing.
Do not accidentally route unrelated application/help/global links through a project browser.
Architecture
Prefer one centralized project-aware navigation/browser service rather than individual WPF handlers launching URLs themselves.
Conceptually:
ProjectLinkLauncher.Open(projectId, uri)
→ resolve project browser preference
→ safely launch URL
Exact design is up to implementation.
Should also eliminate/supersede the current silent Process.Start catch where appropriate so failures can be diagnosed without annoying the user.
Settings semantics
Browser selection is Presentation configuration.
Changing it must:
- NOT build
- NOT remount
- NOT restart monitored apps
- NOT alter Azure polling
Add it to SettingsApplyImpactCatalog with CI coverage when implemented.
Persistence
Persist a stable browser choice where possible.
Handle gracefully:
- selected browser later uninstalled
- executable moved
- browser discovery changes
- System default changed
Fallback should be System default rather than making links dead.
Security
Only launch validated http/https navigation targets through this path.
Do not permit arbitrary command-line execution via a persisted "browser" value.
Be careful with argument quoting if an executable-based implementation is chosen.
Tests when implemented
Cover:
- System default
- discovered browser selection
- project A browser != project B browser
- missing/uninstalled selected browser → safe fallback
- Azure semantic links use project preference (see semantic deep-links issue)
- Site URL uses project preference
- Presentation settings classification
- no build/remount on browser change
- unsafe/non-http(s) target rejected where appropriate
Non-goals
Related
- Semantic Azure deep links (separate issue) will define per-column URLs; this issue defines which browser opens them per project
Use case
Different projects may belong to different contexts/accounts.
Example:
The browser preference belongs to the BuildMonitor project, not globally and not to the Azure connection.
Two projects using the same Azure DevOps connection may intentionally use different browsers.
Proposed Settings UX
Per project:
Open links with:
On Windows, discover installed browsers where practical rather than hard-coding only Chrome/Edge.
System default must always be available.
Do not store credentials/profile secrets.
A custom executable/path option can be investigated but is not required for v1.
Scope of preference
The selected project browser should consistently apply to links opened on behalf of that project, including where applicable:
Audit existing project-originated
Process.Start/browser-launch paths when implementing.Do not accidentally route unrelated application/help/global links through a project browser.
Architecture
Prefer one centralized project-aware navigation/browser service rather than individual WPF handlers launching URLs themselves.
Conceptually:
ProjectLinkLauncher.Open(projectId, uri)→ resolve project browser preference
→ safely launch URL
Exact design is up to implementation.
Should also eliminate/supersede the current silent
Process.Startcatch where appropriate so failures can be diagnosed without annoying the user.Settings semantics
Browser selection is Presentation configuration.
Changing it must:
Add it to
SettingsApplyImpactCatalogwith CI coverage when implemented.Persistence
Persist a stable browser choice where possible.
Handle gracefully:
Fallback should be System default rather than making links dead.
Security
Only launch validated
http/httpsnavigation targets through this path.Do not permit arbitrary command-line execution via a persisted "browser" value.
Be careful with argument quoting if an executable-based implementation is chosen.
Tests when implemented
Cover:
Non-goals
Related