“Microsoft Editor: Spelling & Grammar Checker” browser extension is not replacing text

[niegowski]

📝 Provide detailed reproduction steps (if any)

“Microsoft Editor: Spelling & Grammar Checker” browser extension fails to replace text in the editor.

❓ Possible solution

That extension is detecting whether it can use beforeInput by checking if contenteditable has an attribute: data-slate-editor="true", after I applied such an attribute on CKE5, the spell checker started working (but still has the same issue with missing target ranges same as “LanguageTool”). Also, I noticed that when there are multiple suggestions in the same text node then clicking on the other one makes a replacement in an invalid place. Still, if I modify the renderer to update existing text nodes (instead of replacing them) the same as we do on Android, then it seems to work just great.

---

If you'd like to see this fixed sooner, add a 👍 reaction to this post.

[urbanspr1nter]

It also seems to be that it isn't just not replacing the text, but I see that the selection is not being set correctly too. After attempting to replace, and type, in some cases, I notice the effect in "typing backwards".

[Reinmar]

@urbanspr1nter Any chance someone from the Microsoft Editor team could look into this? We're happy to provide you guidance in how to tackle particular challenges and stabilize the integration. But from my experience most of that may need to happen on the spell checker's side. 

Language Tool, Grammarly and WSC are already integrated with particular rich text editors and some of them already used beforeInput, which makes a lot of sense. IMO, that's the right direction. And apparently MS Editor's spell checker did the same for Slate. IDK if Slate ever handled DOM mutations the way we did but they certainly had problems handling input that didn't come from beforeInput. And I totally understand why they didn't want to invest more in handling input on FF when it didn't support beforeInput (see the linked issue).

Basically, the mutation+diff-based DOM changes handling was a nightmare. We managed to more or less stabilize it for most cases over the years, but there were obvious issues that this mechanism couldn't handle. So, even if we could bring back the mutation handler, that's not going to work flawlessly and there will be no room for improvements there due to the technical limitations of that method. Most importantly, though, I'm strongly against bringing this mechanism back as it's not the right way forward and we see there are better and easier solutions – though, not on our side.

[niegowski]

I was concerned about how such browser extensions could check which method of input to use. Especially when there are old and new CKE5 versions that use different methods and I realized that the extension could try firing beforeinput event and if that event was not canceled then fall back to other methods, for example:

const notCanceled = editable.dispatchEvent( new window.InputEvent( 'beforeinput', {
    bubbles: true,
    cancelable: true,
    inputType: 'insertText',
    data: 'foobar',
    targetRanges: [ new StaticRange( ... ) ]
} ) );

if ( notCanceled ) {
    document.execCommand( 'insertText', false, 'foobar' )
}

[urbanspr1nter]

@Reinmar - Understandable. Actually, we had patched the codebase to fix a few bugs we had found, so I can totally understand your concern. What would be the technical limitations?

As far as being able to modify MS Editor to work differently, I would need to talk to the SME in my team about this. (@Czhang0727) - I am not sure about implications in breaking backwards compatibility, though.

@Reinmar , I am on vacation right now, but would it be okay that we can discuss this more in a call (one to be scheduled with Ludwika) maybe you can help us understand more, and we can try to figure out some way to accommodate.