I’m messing about with ProseMirror in an electron app. One of the issues with electron is that you have to patch in spell checking, which I have done… however it looks like the spell checking is only applied for the word that has focus - see the following:
Does anybody have experience with this stack and is there a better way to mark spelling errors? For instance would it be better to scan the document manually and mark ranges using an approach similar to the linting demo?
If you have access to the file system, doing spell-checking in your own code is viable (dictionaries are big, which makes this approach a bit costly over the web).
Browser’s spell check behavior is not well specified, but in general they do seem to only highlight words that the user ‘touched’ (for some interpretation of touched), and the way ProseMirror is constantly redrawing the DOM display might confuse them.
OK, I think as you say it is some strange interaction between ProseMirror updates and the Electron spell check API as the behaviour doesn’t match the web demos for ProseMirror or react-prosemirror. The behaviour is even more inconsistent than the gif above shows, i.e. sometimes it works and sometimes it doesn’t but other input boxes not controlled by ProseMirror work as expected.
It’s a bundled electron desktop app so including dictionaries isn’t really a problem - they are far smaller than the bundled Chromium files! I’ll add a “linter” thingy to my to do list!
In my experience Chrome “redraws” spellcheck for an entire sentence if the cursor enters it, it seems to be based on sentence-terminating punctuation (not display line). I mocked up a quick demo for another text editor I was working on that cycled the dom selection’s range through each sentence in the modified paragraph before putting it in it’s proper place. I never really stressed it hard, but it passed the proof of concept check. It’s not really the most elegant thing (and it’s bound to lead to some cursor issues) but it might work if you do want to try and get native spell check working
Thanks Matt. Seems like an interesting idea!
Hey, yeah sorry about that. There is little one can do about in JS-land. We tried to push the browser makers via the editing taskforce to give more direct access to the dictionaries to JS. Unfortunately, they seem to think this would be a security issue, because one might draw conclusions from custom entries in the dictionaries.
Say for example someone writes “Piotr is my neighbour”. Usually “Piotr” would be marked as incorrect, because it’s not part of the standard English dictionaries. But in the case of some user it’s not marked. The JS app can then conclude that the user must have added this word to the dictionary at some time. it could then send that information to the server and little by little profile the user. This would be even more true if the browser would give direct access to spelling suggestions.
I suggested the easiest would be to only give access to standard dictionaries without any custom entries, but apparently at least Safari isn’t technically able to do that. A suggestion from browser makers has been to allow the user to mark a range as needing correction.
Interesting, I hadn’t thought of that as an attack method.
As I’m using Electron anyway I have to monkey patch in spell checking using spellchecker so I think the easiest way will be to just use a linter to go through and check the document “manually”. The checking is the easy bit because it will just use the same API that you have to use to get browser checking to work properly 