adam/vscode-front-matter
1
0 Fork 0
mirror of https://github.com/estruyf/vscode-front-matter.git synced 2026-11-03 09:02:19 +01:00
Code Issues 77 Packages Projects Releases Wiki Activity

Issue: Text input becomes slow and occasionally drops characters #781

New Issue
Closed
opened 2026-10-05 03:05:09 +02:00 by adam · 3 comments
adam commented 2026-10-05 03:05:09 +02:00
Owner
Copy link
Copy source

Describe the bug

Text input in a string field has become noticeably slow and can occasionally drop characters while typing.

For example, when entering:

my_normalized_title_35

the input sometimes fails to register one or more characters, requiring me to type them again or correct the value manually.

As I understand it, when filling in a text field, Front Matter debounces the input (300ms), then sends the new value to the Extension Host, which reads the current front matter, updates that field, re-serialises it to YAML, and replaces the whole file. The panel then re-reads the file and refreshes. From a comment in issue #963

This round trip seems to interfere with typing: the field feels sluggish and some keystrokes are lost.

The issue is relatively recent. I have been using the latest beta versions for several months, but I would estimate that I started noticing this approximately two months ago.

I initially noticed it between mid and end of July on a slow Surface Pro, so I initially suspected a hardware performance issue. However, I now experience the same behavior on a significantly faster desktop computer as well.

I deeply suspect the underscore character as its correspond to frontMatter.file.slugSeparator paremater.

The issue occurs while typing at a normal typing speed, with approximately 200–600 ms between keystrokes.

To Reproduce

  1. Open a content item in Front Matter CMS.
  2. Use a field of type string.
  3. Click into the field.
  4. Type a value such as my_normalized_title_35 at a normal typing speed (approximately 200–600 ms between keystrokes).
  5. Notice that the input can feel sluggish and that some characters may not be registered.

My configuration with base and additional files:
https://github.com/poesieland/poesieland.github.io/blob/main/frontmatter.json
https://github.com/poesieland/poesieland.github.io/tree/main/.frontmatter

Expected behavior

Typing should feel responsive and every character should be reliably registered.

Updating the front matter in the background should not interfere with ongoing user input.

Screenshots

Not applicable / difficult to demonstrate with a screenshot, as the issue is primarily related to typing responsiveness and occasionally dropped keystrokes.

Edit: a real sample: today I typed "lumiere_d_automne_35" and instead got "lumiered_atomne_35", dropped characters were a "_" between first and second words then the "u" which is the second character of third word.

Device:

  • OS: Windows 11
  • Front Matter CMS Version: 10.12.324914543 (beta)
  • Browser: Microsoft Edge

Additional context

The issue appears to be related to the interaction between the debounced input update and the subsequent file round trip:

  1. User types in the field.
  2. Input is debounced for 300ms.
  3. The value is sent to the Extension Host.
  4. The Extension Host reads and updates the front matter.
  5. The whole file is re-serialised and replaced.
  6. The panel re-reads the file and refreshes.

When typing continuously, this process seems to occasionally race with the user's input, resulting in noticeable latency and lost characters.

The problem is reproducible on both an older Surface Pro and a significantly faster desktop computer, so it does not appear to be exclusively related to slow hardware.

**Describe the bug** Text input in a `string` field has become noticeably slow and can occasionally drop characters while typing. For example, when entering: ```text id="xqknr6" my_normalized_title_35 ``` the input sometimes fails to register one or more characters, requiring me to type them again or correct the value manually. As I understand it, when filling in a text field, _Front Matter debounces the input (300ms), then sends the new value to the Extension Host, which reads the current front matter, updates that field, re-serialises it to YAML, and replaces the whole file. The panel then re-reads the file and refreshes._ From a comment in issue #963 This round trip seems to interfere with typing: the field feels sluggish and some keystrokes are lost. The issue is relatively recent. I have been using the latest beta versions for several months, but I would estimate that I started noticing this approximately two months ago. I initially noticed it between mid and end of July on a slow Surface Pro, so I initially suspected a hardware performance issue. However, I now experience the same behavior on a significantly faster desktop computer as well. I deeply suspect the underscore character as its correspond to `frontMatter.file.slugSeparator` paremater. The issue occurs while typing at a normal typing speed, with approximately **200–600 ms between keystrokes**. **To Reproduce** 1. Open a content item in Front Matter CMS. 2. Use a field of type `string`. 3. Click into the field. 4. Type a value such as `my_normalized_title_35` at a normal typing speed (approximately 200–600 ms between keystrokes). 5. Notice that the input can feel sluggish and that some characters may not be registered. My configuration with base and additional files: https://github.com/poesieland/poesieland.github.io/blob/main/frontmatter.json https://github.com/poesieland/poesieland.github.io/tree/main/.frontmatter **Expected behavior** Typing should feel responsive and every character should be reliably registered. Updating the front matter in the background should not interfere with ongoing user input. **Screenshots** Not applicable / difficult to demonstrate with a screenshot, as the issue is primarily related to typing responsiveness and occasionally dropped keystrokes. **Edit**: a real sample: today I typed "lumiere_d_automne_35" and instead got "lumiered_atomne_35", dropped characters were a "_" between first and second words then the "u" which is the second character of third word. **Device:** * OS: Windows 11 * Front Matter CMS Version: 10.12.324914543 (beta) * Browser: Microsoft Edge **Additional context** The issue appears to be related to the interaction between the debounced input update and the subsequent file round trip: 1. User types in the field. 2. Input is debounced for 300ms. 3. The value is sent to the Extension Host. 4. The Extension Host reads and updates the front matter. 5. The whole file is re-serialised and replaced. 6. The panel re-reads the file and refreshes. When typing continuously, this process seems to occasionally race with the user's input, resulting in noticeable latency and lost characters. The problem is reproducible on both an older Surface Pro and a significantly faster desktop computer, so it does not appear to be exclusively related to slow hardware. <!-- github-sync-id:5504812783 -->
adam commented 2026-10-05 03:05:10 +02:00
Author
Owner
Copy link
Copy source

Thanks for the detailed report and the real sample — that made this easy to pin down.

What was happening

Your understanding of the round trip is right, and the problem was in how the text field decided whether an incoming value or your local text should win. It used a timestamp of the last keystroke rather than tracking what it had actually sent, so when the round trip took longer than the 300ms debounce plus your typing gap:

  1. The echo of an older update (e.g. lumiere) arrived after you had already typed _, and overwrote the input.
  2. When the later echo (lumiere_) arrived while you were typing d, it was correctly rejected, but it also cleared the flag that allowed the next debounced send — so the pending value was silently never sent.

Result: lumiered_…, exactly what you saw. Underscores were hit more often simply because of the small pause before Shift+_, which tends to land right after a debounce boundary.

It surfaced around 10.11.0 because the per-update work on the extension host got heavier (content health checks, more panel refreshes), which pushed the round trip past the threshold where this race triggers. slugSeparator wasn't involved.

Fix

Commit c3b5418b26: the string and wysiwyg fields now track the last value they sent/accepted, so they recognise their own echoes and never let a stale one overwrite pending local edits, and a rejected incoming value no longer blocks the next send. I replayed your lumiere_d_automne_35 example against the old and new component with simulated round-trip latencies of 300–800ms and typing gaps of 150–550ms: the old code dropped characters in 12 of 16 scenarios, the fix in none.

This will be in the next beta build. Let me know if you still see it after updating.

Thanks for the detailed report and the real sample — that made this easy to pin down. **What was happening** Your understanding of the round trip is right, and the problem was in how the text field decided whether an incoming value or your local text should win. It used a timestamp of the last keystroke rather than tracking what it had actually sent, so when the round trip took longer than the 300ms debounce plus your typing gap: 1. The *echo of an older update* (e.g. `lumiere`) arrived after you had already typed `_`, and overwrote the input. 2. When the later echo (`lumiere_`) arrived while you were typing `d`, it was correctly rejected, but it also cleared the flag that allowed the next debounced send — so the pending value was silently never sent. Result: `lumiered_…`, exactly what you saw. Underscores were hit more often simply because of the small pause before Shift+`_`, which tends to land right after a debounce boundary. It surfaced around 10.11.0 because the per-update work on the extension host got heavier (content health checks, more panel refreshes), which pushed the round trip past the threshold where this race triggers. `slugSeparator` wasn't involved. **Fix** Commit c3b5418b26cf94e63d5822998e223f816c5e2a53: the `string` and `wysiwyg` fields now track the last value they sent/accepted, so they recognise their own echoes and never let a stale one overwrite pending local edits, and a rejected incoming value no longer blocks the next send. I replayed your `lumiere_d_automne_35` example against the old and new component with simulated round-trip latencies of 300–800ms and typing gaps of 150–550ms: the old code dropped characters in 12 of 16 scenarios, the fix in none. This will be in the next beta build. Let me know if you still see it after updating. <!-- github-comment-id:5752423082 -->
adam commented 2026-10-05 03:05:11 +02:00
Author
Owner
Copy link
Copy source

Thanks a lot for the explanation! If beta version 10.12.355353492 contains the fix, today I happily typed premier_matin_d_automne_35! So you can close the issue. Indeed, I see smoothier behavior of the FM text input, totally fine.

Thanks a lot for the explanation! If beta version 10.12.355353492 contains the fix, today I happily typed `premier_matin_d_automne_35`! So you can close the issue. Indeed, I see smoothier behavior of the FM text input, totally fine. <!-- github-comment-id:5802195003 -->
adam commented 2026-10-05 03:05:11 +02:00
Author
Owner
Copy link
Copy source

Thanks @postb99 for verifying

Thanks @postb99 for verifying <!-- github-comment-id:5816340777 -->
adam closed this issue 2026-10-27 13:26:48 +01:00
Sign in to join this conversation.
No Branch/Tag Specified
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
adam (Adam Wojcieszonek)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: adam/vscode-front-matter#781