Web Spell Checker - "finish checking" takes ages to finish

[Wiktor Walc]

When having a larger document, the SpellChecker dialog becomes useless. I have tried editing the following document in CKEditor:

​http://en.wikipedia.org/w/index.php?title=Black_hole&printable=yes

and after opening the "SpellChecker" dialog (with the "Check Spelling" button), after I clicked "Finish Checking" button inside of the dialog, it didn't close in a reasonable amount of time (it took almost 9 minutes, I have pretty fast internet connection). I have tested it in IE8.

To reproduce load the attached HTML source and use WSC.

I have no idea how spell checker works, but it looks like the problem is that the data is sent in a really small chunks, thus checking the whole document requires hundreds of HTTP requests.

There is one more thing that I do not understand here: I have pressed the "Check Spelling" button, I did not change anything in the dialog and just pressed the "Finish Checking" button. Why is it taking so long if I did not change the document at all?

If it really has to take a lot of time, we could at least display an estimated time required to finish processing, because it is definitely not obvious that this operation may take so long.

[WebSpellChecker.net]

Thank you for this report. SpellChecker.net have added this bug into defect tracking system. We are working on it and will provide fix as soon as possible.

[WebSpellChecker.net]

Here are two problems

1. Slow transport which is used to pass data from SpellChecker back to the editor. This transport was developed for FCKeditor and then was used for CKEditor. It is an surrogate for SpellChecker.net sproxy script (​http://wiki.spellchecker.net/doku.php?id=instructions), which reload data with small chunks between spellchecker site URL and target site URL. The solution is ok for most of Internet users but is not good for users who utilize spellchecker to check and correct big enough texts (50K and more). Adding progress indication may change user experience but will not solve the problem. The solution we see now is to improve WSC plug-in to support sproxy (for customers who are interested in it) and probably utilize some new tequniques like Message Passing for some browsers, but this is an step-back solution. Other alternative here is to work on new WebSpellChecker based on SCAYT core, which will not have such limitations as current solution have. Both solutions requires significant time to implement (around month).

2. Spellchecker does not check whether document is changed and starts to pass data back to the editor instead of just closing the spellchecker window. The solution for this problem is to add functionality on SpellChecker.net side to check whether there was any changes and take into account this information when "Finish Checking" was clicked. This is quick solution.

We suggest to implement 2. and schedule one of solutions for 1. We are open to discuss any other options.

[Frederico Caldeira Knabben]

I think it's senseless to maintain different spellchecking solutions. SpellChecker.net would benefit a lot by having the WSC UI using the SCAYT core engine. It looks like the hardest path, but it's the most beneficial approach for the long run.

[WebSpellChecker.net]

We do agree. We will rise the priority of this task in our backlog and will start to implement it within a month.

[Garry Yao]

The performance issue is still there.

[Frank]

I experienced this issue as well with a .NET implementation...looking forward to the fix.

[WebSpellChecker.net]

postMessage cross-domain transport implemented for browsers which support postMessage.