Partial words being marked as typos

[winhamwr]

I did some editing today and noticed that on at least two occasions, spellcheck marked a word as a typo because it chopped my word. I'm working on the exact reproduction steps, but it was while I was just typing up new content and using my keyboard to navigate around and edit it.

Example 1

<p><a data-cke-saved-href="https://en.wikipedia.org/wiki/Technical_debt" href="https://en.wikipedia.org/wiki/Technical_debt">Technical Debt</a>&nbsp;is a metaphor used to describe areas where we've consciously&nbsp;chosen to trade off the short term versus long term by building something <span class="nanospell-typo"></span><span class="nanospell-typo"><span class="nanospell-typo">qui</span>ckly</span> instead of in the best way. Just like using a credit card to pay for <span class="nanospell-typo"></span><span class="nanospell-typo"><span class="nanospell-typo">thi</span>ngs</span> in our personal life, it can be a smart strategy as long as we keep it under control.</p>

• "quickly" was split into "qui" and "ckly"
• "things was split into "thi" and "ngs"

  Example 2

<p>The flex engineer helps to <span class="nanospell-typo">kee</span>p this debt under control by taking projects to improve the development process, upgrade libraries, refactor code, and optimize performance.</p>

"keep" was split into "kee" and "p", but "p" wasn't marked as a typo.

[winhamwr]

I was able to reproduce this by just typing at my normal speed. No navigation necessary. In the paragraph I just typed, it happened with 3 different words: "squashing", "will", and "improvements"

The typo mark appeared while I was still in the middle of typing each word, so it feels like some sort of timing issue. Maybe if a spellcheck request/response goes fast enough that I didn't have enough time to add additional letters to the partial word, this happens (since adding letters would have changed the word, confusing the code that tries to mark it as a typo)? With the typo for "will", I definitely paused between typing the "wil" and the "l" because I was considering an alternative wording.

<p>Twice per month, the Flex Engineer will dedicate an entire day to <span class="nanospell-typo">squ</span>ashing usability issues. Our User Experience Design Lead, Jana, <span class="nanospell-typo">wil</span>l determine the priority and the focus will be on high-impact, low-effort <span class="nanospell-typo"><span class="nanospell-typo"></span><span class="nanospell-typo">improv</span>ements</span>.&nbsp;</p>

"improvements" started out by just marking "improv" as a typo (which is where I was at the time). I finished the word, typed some other stuff that I deleted, and then backspaced into the word to add a period. That seemed to trigger the remaining "ements" section being marked as a typo.

[winhamwr]

This was all using Chrome. I can try to reproduce by using another browser to editor next time, if that will help. Just let me know which browser to try.

[caffodian]

Hmm. I don't think we need other browsers, though I will need to look into this bug. Spans are supposed to be removed on the current word, but maybe there is an order of events that is wrong here.

[caffodian]

Interesting.

Seems like the span is not being removed on typing if you never leave the word. Probably because the cursor is outside of the span.

If you press enter on a block, it seems to fix this.

[caffodian]

Argh.

It does not "fix" it actually, it marks it correctly but you can't click on the correct thing.

[caffodian]

Possibly a side effect or an unfixed instance of #25 which also nested spellcheck spans.

Actually, the partial marking is the step before you end up into a similar state to what #25 fixed.

[caffodian]

Plan for a repro test:

part 1

• Set a typo with cursor at end of typo
• wait for spellcheck
• type some more
• check for single or 0 spans

part 2

not sure yet, need to figure out why the span is not being ignored. maybe make a safety check where we clear any spans within the current word range, first.

[caffodian]

For case 1, we don't have a good way to pause when typing has begun, but before spellcheck goes. hm.

[caffodian]

I suspect the clearing not working is because it is:

<span class="nanospell-typo">qui</span>^

and not

<span class="nanospell-typo">qui^</span>

[caffodian]

Very strange thing. Now I cannot reliably reproduce this.

[caffodian]

Some of this weirdness has something to do with the cache.

If I get "sho" into the cache as a typo, it becomes impossible to type "shouldn't without the first 3 getting marked as typo, super quickly.

[winhamwr]

The cache just makes it worse, because once you get one bugged typo, it then guarantees that you'll see it for repeated words. Fix the original problem and it seems like the cache will fix itself.

[caffodian]

So here is why it happens:

We changed things in #16 so that the walker just ignores spans, assumption being that if something is already a typo, we don't care.

What this does not account for, is where you add things onto the span afterwards.

Possible fixes

• improve the "clear a span when you stick things onto it" handling
• revert #16 or special case it to only ignore spans where the whole word is covered. (need to ensure this doesn't cause nested typo spans again)

[caffodian]

The test shows this:

• type qui
• qui is marked as a typo
• type "ckly"
• the word "ckly" is sent to the spellcheck API, but not "qui" (beacuse it is already marked)

[caffodian]

Clearing the spans properly might be the correct thing to do, but it's unclear where and whether all possibly cases can be easily handled.

For example:

<p>qui^</p>

then paste

ly </p><p>some other paragraph</p>

The cursor will end up in the second paragraph and it won't be obvious that you have to go back and fix some previous paragraph tag. There doesn't seem to be a common sense way to do this from the generic change event so we'd probably need to handle all sorts of stuff I haven't thought of yet.

[caffodian]

Quicker fix seems to be : revert the changes to not re-check already marked spans + make it so already marked spans cannot be remarked

[caffodian]

Multi-span thing that causes problems - we shrink the range to only have the text, but we need to clean up the leftover span afterwards.

[caffodian]

Other ugly case

Potentially you could have multiple typos being joined. for ex:

<span>foo</span> ^<span>bar</span>, hit backspace.

[caffodian]

That one is probably a whole other mess though.

[caffodian]

What we should do:

remove spellcheck spans within the word range, but not do anything if the span already wraps the whole word.

Before shrinking the range to mark text, first check if the range covers an existing typo span. (this is tricky, need to confirm if the ranges include existing spans, or end inside them)

If so, do nothing, else clear any ranges within + mark the range.

[caffodian]

notes on Trying the "ignore the current word" approach:

• walking the range normally and then trying to detect if the cursor is inside the current word, is actually really hard (awful case: <b>foooooooooooooo</b>as^df<em>barrrrrrrrr</em> hello )
• it is surprisingly terrible to do range comparisons, or I'm missing something...

[caffodian]

after having stepped back, it's quite annoying that you seemingly can't convert CKEditor ranges to w3c spec ranges. Because at least according to MDN, https://developer.mozilla.org/en-US/docs/Web/API/Range/compareBoundaryPoints would have been very useful

[caffodian]

Tried moving some of the existing typo skipping back into the wordwalker.

This then led to another degenerate case around range.optimize():

<li><span>typozzz</span></li> will optimize to contain the entire list item, which then means you end up having to find all spans within it and remove them anyway. So this kinda sucks. Back to having the word walker return everything and then fix/ignore existing typos later on.

[caffodian]

various bad approaches later (and a lot of weird edge cases), attempt to filter the fragment before re-inserting.

[caffodian]

That failed, because the fragment doesn't actually contain CKEditor nodes, but we can just as well remove spelllcheck spans from the spellcheck span. Why didn't I think of that earlier.

[winhamwr]

w3c spec ranges

Abandon all hope, ye who enter here. Every browser has a slightly different implementation of this spec. It really sucks.

[caffodian]

Abandon all hope, ye who enter here. Every browser has a slightly different implementation of this spec. It really sucks.

Yea, I spent about 10 mins reading it and noped out.