fix: Send correct clientContext in web extension

Enrique Alcántararequested to merge
fix-client-context-info-in-web-ide into main

Description

This change adds support for providing custom client context information to the language server. Previously, the system had a hardcoded way of identifying itself to the language server, but now it can be configured differently for different environments.

The main improvement is that the browser version (Web IDE) and desktop version of the extension can now send different identification information to the language server. The browser version identifies itself as "GitLab Web IDE" while the desktop version identifies as "Visual Studio Code". This allows the language server to know which environment it's running in and potentially behave differently based on that context.

Related Issues

How has this been tested?

  • If src/browser or src/common has been modified, please consider interoperability with the Web IDE. See Running the Extension in WebIDE.
  • Consider an end-to-end test for significant new features that aren't covered by integration tests.
  1. Start the Web IDE using yarn start:example .
  2. In the gitlab-vscode-extension project, run npm run watch:browser.
  3. Open the Web IDE and enter the test project configuration. I suggest pointing to http://gitlab.com because it allows you to test direct connection from the Web IDE and the user tracking endpoints.
  4. Enable the gitlab.featureFlags.languageServerWebIDE feature flag on the Web IDE User Settings.
  5. Trigger code suggestions by editing a file.
  6. In the web browser's developer tools, when opening the Network Tab, you'll see that requests to the endpoint https://gitlab.com/api/v4/usage_data/track_event should have metadata that indicates the IDE name is GitLab Web IDE not "Visual Studio Code".

Screenshots (if appropriate)

Screenshot 2025-09-30 at 13.18.45.png

What CHANGELOG entry will this MR create?

  • fix: Bug fix fixes - a user-facing issue in production - included in changelog
  • feature: New feature - a user-facing change which adds functionality - included in changelog
  • BREAKING CHANGE: (fix or feature that would cause existing functionality to change) - should bump major version, mentioned in the changelog
  • None - other non-user-facing changes
Edited by Enrique Alcántara

Merge request reports