Summary

The color picker hover widget closes unexpectedly while the user is still actively dragging inside it, discarding the in-progress color selection.

Observed behavior: Hovering a color swatch in a CSS file opens the color picker. Clicking and dragging inside the saturation/value box toward an extreme value (e.g. pure black or pure white) causes the picker to close the instant the cursor moves outside the widget's bounds — even though the mouse button is still held down.

Expected behavior: Once a drag has started inside the color picker, it should remain open and continue tracking the drag until the mouse button is released, regardless of where the cursor is on screen.

Root Cause

ContentHoverController (src/vs/editor/contrib/hover/browser/contentHoverController.ts) uses two separate, independently-maintained checks to decide whether the hover should stay open on mouse activity:

• _shouldKeepCurrentHover() — used by the main branch of _onEditorMouseMove — correctly treats "color picker visible AND mouse button down" as a reason to keep the hover open.
• _shouldKeepHoverWidgetVisible() — a separate, narrower helper used by _onEditorMouseDown, _onEditorMouseLeave, and an early-return branch of _onEditorMouseMove — had no such check. It only considered whether the pointer was currently over the widget DOM, a resize handle, or the color decorator glyph.

When dragging toward a corner of the saturation box, the pointer leaves the widget's bounds while the mouse button is still down. This triggers _onEditorMouseLeave (or the early-return in _onEditorMouseMove), both of which rely on _shouldKeepHoverWidgetVisible(). Since that check has no awareness of an in-progress color drag, it returns false, and hideContentHover() is called — disposing the picker mid-drag. _shouldKeepCurrentHover(), which does have the correct logic, is never reached because these code paths short-circuit before it.

Solution

Extracted the "user might be actively choosing a color" condition into a single shared private method, and used it in _shouldKeepHoverWidgetVisible() so all three affected call sites (_onEditorMouseDown, _onEditorMouseLeave, _onEditorMouseMove) inherit the fix consistently, instead of the condition being duplicated across two separate helpers.

+ private _isMaybeChoosingColor(): boolean {
+     return !!this._contentWidget?.isColorPickerVisible && this._isMouseDown;
+ }
+
  private _shouldKeepHoverWidgetVisible(mouseEvent: IPartialEditorMouseEvent): boolean {
-     return this._isMouseOnContentHoverWidget(mouseEvent) || this._isContentWidgetResizing() || isOnColorDecorator(mouseEvent);
+     return this._isMouseOnContentHoverWidget(mouseEvent) || this._isContentWidgetResizing() || isOnColorDecorator(mouseEvent) || this._isMaybeChoosingColor();
  }

The previously-duplicated inline check inside _shouldKeepCurrentHover() now calls the same shared helper instead of re-implementing the condition.

Why this does not introduce regressions: _isMaybeChoosingColor() only evaluates true when a color picker is actually visible. Every other case is unaffected, since no color picker is present in those scenarios and the condition falls through to the prior (unchanged) behavior.

Testing

• Content Hover test suite — passing
• Color-related suites — passing
• npm run typecheck-client — clean
• Manually verified via an isolated Code OSS instance driven over CDP: reproduced the reported drag-outside-bounds scenario, confirmed the picker is hidden mid-drag without the fix and stays visible with it, and confirmed it still closes normally on mouse release.
• Confirmed the pre-existing text-selection-drag-hides-hover scenario is unaffected, since it doesn't involve a color picker.

Files Changed

• src/vs/editor/contrib/hover/browser/contentHoverController.ts — added _isMaybeChoosingColor() helper, wired into _shouldKeepHoverWidgetVisible(); removed the duplicated inline check from _shouldKeepCurrentHover().

Issue Reference

Fixes #327430

Checklist

• The reported issue is fixed and manually verified
• Code follows the project's coding style
• Existing functionality is preserved
• No unnecessary files were modified
• Relevant existing tests pass
• Manual testing was completed
• Documentation update (not applicable — internal behavioral bug fix)