STR:

1. Open data:text/html,<textarea rows=20 cols=50>That undfgdfg seems OK.</textarea>
2. Click immediately after "undfgdfg".
3. Add a space.
4. Remove the space.
5. Press the "End" key.
6. Add a space and write something.

Expected:
"undfgdfg" would be marked as misspelled after step 5.

Actual:
it isn't.

Clicking outside the textarea fixes this, presumably because it scheduled a full spellchecking. Happened on Ubuntu 20.04.

I can reproduce this in Nightly94.0a1 Windows10.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=d10dc4dc4162b15320bf468adaf5cf0859666c23&tochange=2ab582bacc98fecfc3cc52b3f275a23ff40a683f

I confirmed that Setting dom.keyboardevent.keypress.dispatch_non_printable_keys_only_system_group_in_content to false fixed this issue.

It means that spellchecker has a keypress event listener in the default group.

Changing severity to S3 because of not serious, but maybe annoying bug.

Currently, mozInlineSpellChecker handles events in the default group. This
means that the listener may not run if web app stops the propagation. For
keeping the event listener order as far as possible, this patch changes to
listen to the event at capturing phase in the system group (editor handles
the events at bubbling phase in the system group).

Additionally, it listens to keypress events for handling caret/selection
changes. However, they should be handled at keydown because those keys
are not printable. Therefore, this patch changes to listen to keydown
events, but this could change the race between running the scheduled spellcheck
and following keypress event which is dispatched only for chrome code and
C++ event listeners. However, this may not change it actually because the
race is changed only when the following keypress event delays too much.
https://searchfox.org/mozilla-central/rev/2eebd6e256fa0355e08421265e57ee1307836d92/extensions/spellcheck/src/mozInlineSpellChecker.cpp#503-504

https://hg.mozilla.org/mozilla-central/rev/ca8fcd42078a