This field test was against VS Code.
The issue was VS Code #314457:
https://github.com/microsoft/vscode/issues/314457
The reported problem involved editor input behavior jumping at certain zoom levels.
This is a different class of failure than the earlier Scarab field tests.
Not provider config.
Not retrieval context.
Not cache authority.
Not image optimization.
This was an editor/browser geometry boundary.
Scarab Diagnostic Suite surfaced the issue as an input geometry parity problem.
The local finding was narrow:
VS Code’s native EditContext path could hand fractional selection, control, and character DOMRect bounds into the browser API, while nearby editor rendering paths already round visible geometry.
That matters because editor input behavior depends on extremely precise agreement between:
what the editor renders,
what the browser thinks the input geometry is,
and where the user’s caret/selection should be.
If those geometry paths disagree, small fractional differences can become visible as input movement or jumping behavior, especially under zoom.
The local repair candidate is intentionally small.
It does not redesign editor layout.
It does not change broad rendering behavior.
It does not touch unrelated input handling.
The patch adds a focused native EditContext geometry helper and rounds the relevant bounds only at the native EditContext handoff.
The changed surface is limited to:
- native EditContext bounds handling
- a small geometry helper
- a focused regression test
Local validation passed across TypeScript native compile checks, client transpilation, node test, browser test, layer validation, and diff checks.
Field Test #010
Project: VS Code
Issue type: editor input / zoom behavior
Boundary: rendered editor geometry vs native browser EditContext bounds
Result: narrow local repair candidate and regression test
Status: issue-thread comment prepared before PR because the issue is assigned
The important part of this field test is that Scarab identified a mechanical boundary.
The bug shape was not “the editor is broken.”
It was:
visible editor geometry and native input geometry may not be using the same rounding truth
That is smaller.
That is testable.
That is repairable.
Scarab’s field tests are continuing to show the same pattern across very different systems:
when software fails, the useful question is often not “where is the bug?”
It is:
which boundary stopped preserving truth?
Top comments (0)