Korean language heatmap WPM calculation inaccurate

[Beaux44]

Did you clear cache before opening an issue?

• I have cleared my cache

Is there an existing issue for this?

• I have searched the existing open and closed issues

Does the issue happen when logged in?

Yes

Does the issue happen when logged out?

Yes

Does the issue happen in incognito mode when logged in?

Yes

Does the issue happen in incognito mode when logged out?

Yes

Account name

No response

Account config

No response

Current Behavior

The overall WPM graph looks correct, however when looking at the heatmap, you can see in the attached images the heatmap show WPM values several times higher than the average for every word, even showing values like 72,000 WPM or more, or just overall weird results, such as NaN, or the exact same number for a bunch of words.

It seems like the WPM gets much higher as the number of unicode characters decrease, especially when a word is just a single unicode character (made up of multiple keystrokes).

Expected Behavior

It should show a reasonable, accurate WPM in the heatmap.

Steps To Reproduce

1. Select Korean language (any variant)
2. Finish a test
3. Click Toggle words history if off
4. Click Toggle burst heatmap if off

Environment

• OS: Windows 11

• Browser: Librewolf

• Browser Version: 141.0-1 (64-bit)

• OS: Windows 11

• Browser: Google Chrome

• Browser Version: 143.0.7499.170 (Official Build) (64-bit)

(I tried both)

Anything else?

No response

[Leonabcd123]

My best guess would be the following:

When calculating burst, we call calculateBurst, which calculates the amount of time taken to write the word by doing the following:

const timeToWrite = (performance.now() - TestInput.currentBurstStart) / 1000;

The smaller timeToWrite is, the bigger the resulting burst will be. We set TestInput.currentBurstStart in onInsertText right after typing the first character of a word:

if (testInput.length === 0) {
  TestInput.setBurstStart(now);
}

And we call calculateBurst when moving to the next word. What happens in Korean (and probably other languages that have composition) is that if you finish the current word mid composition by hitting space, and the whole word was still in composition (so no part of it was finished, it was all part of same composition event), what will happen is that we will set TestInput.currentBurstStart to now (because we haven't typed any part of the word outside of the composition event, testInput.length will be 0, and thus will enter the if statement mentioned above), and because we entered a space, we will also move on to the next word which will call calculateBurst. This causes a very small time difference between performance.now() in calculateBurst and TestInput.currentBurstStart, which will cause timeToWrite to be very small, which will cause the final burst speed to be higher than expected.

Fix: Maybe we can call TestInput.setBurstStart when starting the composition instead of when the composition ended and the first letter has been typed?

[biplavbarua]

Hi! I can help fix this.

It looks like the WPM spikes (e.g., 72,000 WPM) are caused by the way calculateBurst and WPM logic handle the rapid updates during Hangul (IME) composition. When a character is 'committed' or updated via IME, the time delta between events might be essentially zero or extremely small, leading to a division-by-zero or massive number when calculating (chars * 60) / time.

I propose to:

1. Review Hangul Integration: deeper dive into how hangul-js interacts with test-stats.ts.
2. Filter Zero-Time Updates: Modify calculateBurst and relevant WPM functions to strictly guard against zero or near-zero time deltas.
3. Debounce/Smooth Calculations: Implement a safeguard to ignore intermediate IME composition states for the instant WPM calculation, or ensure we only calculate using the start/end time of the completed character block rather than intermediate keystrokes.

I'll start by simulating the issue locally with header inputs and applying the fix.