[PawelTroka]

Problem

Refs #293. Linux/Mono autocomplete starts with an effectively screen-wide (up to 2,000 px) menu, does not bound the reference popup relative to actual remaining display space, and can show reference help before its completion list is placed. In the original WinForms popup, a click can also cause a focus-loss close before the Mono list receives the selecting event.

This deliberately retains the current WinForms ToolStripDropDown / AutocompleteListView / MonoReferenceText architecture. The new layout/focus/selection behavior is compiled under __MonoCS__, leaving the working Windows HTML reference and completion policy intact.

Changes

• Measure up to 64 matching labels plus the selected item and bound the menu to a 580 × 360 DPI-scaled maximum instead of using a 2,000 × 420 preferred size on Mono.
• Keep scrolling enabled, disable Mono ToolStrip/control autosizing that overrides the measured list, and align the menu with the caret inside its monitor's working area (including above the caret when necessary).
• Defer opening a function reference until the completion list is shown. Position the plain-text help to whichever side has space, or above/below on constrained displays; reduce short help popups where Mono's RichTextBox can measure their content.
• Preserve editor keyboard focus during completion; avoid closing a clicked list before the click arrives; accept an item with a single native pointer click on Mono. Keep Enter, arrows, PageUp/Down, Escape and Ctrl+Space working.
• Use a readable 10-point font for Mono's managed, offline reference fallback.

GUI acceptance and screenshot evidence

Extended the existing Mono-Validate smoke suite with real X11 events via xdotool on Mono/WinForms (not simulated method calls). Cases cover:

• Native typing and fuzzy/prefix filtering, visible/appropriately sized list, reference text and focus preservation.
• Down + Enter insertion, real pointer click insertion, scrolling through 42 candidates with PageDown/Up.
• Escape and three repeated Ctrl+Space open/close cycles.
• Relocation to the lower-right screen corner with popup and help bounds inside the working area.
• Native desktop screenshot: artifacts/mono/Release/autocomplete-after.png (uploaded by the Mono CI workflow).

Before: original issue #293 screenshot (948 × 536, user-supplied).
After: actual painted popup screenshot (Ubuntu 24.04, exact-head 2394ffc); compared with the preceding run that showed mapped-but-unpainted windows.

Review / validation status

• Scope remains Mono-specific; no intentional change to the Windows behavior or previously merged Fit autocomplete help popups to short descriptions #260 HTML help sizing.
• Existing Mono acceptance pipeline extended with native keyboard/pointer coverage and a real screen capture.
• Exact-head Mono/X11 acceptance: 44/44 cases pass at 2394ffcd953acceac68dac69d6678149397456af; screen captures inspected, including visible completion and help pixels.
• Windows Cake validation: all four exact-head jobs succeeded (desktop tests, Core tests, Core integration tests, Web API integration tests).
• Physical Linux desktop / compositor / DPI acceptance.

This is intentionally draft. Do not merge without the repository owner's explicit approval.

October 27 validation follow-up (in progress)

Current head: 2394ffcd953acceac68dac69d6678149397456af (commit).

• Computator.NET.slnx now links the tracked build/mono/SmokeTests/MonoAutocompleteTests.cs source (a21a54f); original Windows, solution, reference, web and packaging failures had the same developer-solution inventory error.
• Exact predecessor a21a54fed286c1129fb6410cdb69a6ae3178ad26 passed native Mono CI with 44/44 smoke cases and developer solution CI. Native Mono XML and X11 screenshots were inspected.
• That predecessor's X11 screenshot unexpectedly showed the form and editor without painted completion or reference windows, although their X11 map states and bounds looked correct and native input/selection tests passed. The older Oct 26 passing run did capture painted suggestions/help. This is a screen-capture/paint-visibility regression that was not detected by the original color-count assertion.
• CaptureAutocompleteX11 now requires genuine light popup-content pixels within the menu and reference rectangles, tries native repaint/pumping for up to five seconds, and saves the failure image if the controls are still unpainted. It does not synthesize screenshots or weaken visibility assertions (2394ffc).
• The latest exact-head Mono/X11 run passes 44/44. Its artifact includes a visually inspected autocomplete-after.png with real painted suggestions and reference help, and the XML confirms the new pixel-visibility assertion passed. The Windows Cake run subsequently completed all four jobs successfully. Exact-head GSL source and GSL packaged workflows passed too. All 21/21 exact-head GitHub Actions workflows completed successfully, including release identity and candidate evidence. No failures or skipped workflows were reported for 2394ffcd953acceac68dac69d6678149397456af.
• PR feat(mono): native interactive f(x,y) 3D surfaces in Linux WinForms #296 is independent of the autocomplete production changes. When combining all three PRs, retain both xdotool x11-utils (here) and libxtst6 (feat(mono): native interactive f(x,y) 3D surfaces in Linux WinForms #296/fix(mono): ensure active complex chart paints above overlapping native charts (#295) #298), reconcile Mono validate.sh evidence cleanup and preserve distinct smoke-test entry points; combined-branch CI has not yet been executed.

Physical Linux desktop/compositor and DPI matrix acceptance remains unverified. Draft; no merge without approval.

[PawelTroka]

Mono/X11 runtime investigation (26 October 2026)

The first exact-head smoke implementation compiled, and 43 pre-existing Mono cases passed, but the new real-X11 autocomplete acceptance was initially failing.

The failure is not just a test threshold: native X11 diagnostics found the hosted completion list outside the actual popup geometry. Example recorded by xwininfo:

• Completion dropdown: x=119, y=152, 244×95
• Completion-list child: x=291, y=288, 240×91 (fully outside its hosting window)
• The list's X/Y offset matches stale centered host dimensions, so mouse clicks do not hit the completion entries and no visible suggestions are painted. Keyboard-only selection had already passed.

The proposed fix sets Mono's ToolStripControlHost.ControlAlign to TopLeft so a content-sized completion list remains inside its dropdown on reflow.

Latest exact-head Mono test: workflow run 40325020999; queued as of this note. Do not treat the fix as validated until real X11 mouse insertion, scrolling, placement, and screenshot checks pass. Keep this PR draft and do not merge without explicit owner approval.