editor: Fix right-click context menus failing to appear at pixel-snapped scroll positions

[amtoaer]

Objective

Fixes #56136.

The issue was initially reported while an agent was generating code. Later reports reproduced it during manual editing and with AI disabled, ruling out the agent as the cause.

At fractional display scales, the editor's right-click context menu could fail to appear at specific discrete scroll positions. Scrolling one line at a time could make the menu alternate between hidden and visible, even when its anchor remained within the viewport.

Solution

The editor-specific changes in #54728 started pixel-snapping the vertical scroll position used by EditorElement to derive and render visible rows. However, Editor::display_to_pixel_point continued using the raw scroll position for its visibility check and vertical projection.

When a downward pixel snap crossed an integer display-row boundary, EditorElement treated the preceding row as the visible range start. display_to_pixel_point then rejected that row as being above the raw viewport. Mouse context menu layout returned early before inspecting the actual clicked anchor, leaving the menu state present without rendering its element.

This change applies the same line-height and display-scale pixel snapping in display_to_pixel_point. Its visibility check and coordinate projection now use the coordinate space actually rendered by the editor.

A test-support-only scale-factor setter was also added so GPUI tests can exercise fractional display scaling without depending on the host display.

Testing

Added a GPUI regression test using 100 plain-text lines so the editor can scroll. The test uses a 1.25 scale factor and a 14px font with 1.3 relative line height. The resulting 18.2px line height is rounded to 18px, producing exactly 22.5 device pixels per row.

At a raw scroll position of one row, midpoint-toward-zero snapping maps 22.5 device pixels to 22, or approximately 0.978 rows. This reproduces the old boundary mismatch where the snapped visible range starts at row zero while the raw visibility check starts at row one.

The test pins these values with precondition assertions. Row five and an in-bounds click keep the actual source visible, while checking the rendered bounds of the Copy item ensures the test does not pass merely because menu state was created.

Manually verified that scrolling from the start of a document no longer makes the context menu alternate between hidden and visible.

Self-Review Checklist:

• I've reviewed my own diff for quality, security, and reliability
• Unsafe blocks (if any) have justifying comments
• The content adheres to Zed's UI standards (UX/UI and icon guidelines)
• Tests cover the new/changed behavior
• Performance impact has been considered and is acceptable

Showcase

Before:

2026-07-20_23-36-05.mp4

After:

2026-07-20_23-38-15.mp4

---

Release Notes:

• Fixed editor right-click context menus intermittently failing to appear at certain scroll positions.

[ChristopherBiscardi]

thanks!