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 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 the current word is a single letter, and you finish it mid composition, and you hit space, what will happen is that we will set TestInput.currentBurstStart to now (because this is the first letter of the word, 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?