Created attachment 302512 [details] test case To describe the problem imagine that you are creating an advanced WYSIWYG editor based on contenteditable. You are modifying the DOM directly (as some of the document's execCommand methods are not sufficient for you) and at some point the spell check for the element is lost. The suggested method (until https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/forceSpellCheck is ready and implemented in WebKit) is to move the caret to the beginning of the element and then by modifying the selection, moving the caret to the end of the element (that's what the attached test case is doing) forces the spell check to be renewed. To speak precisely it forced as after the bug 129024 the spell checking is now done async. Now, if we are moving the caret in a loop then the spell check is scheduled inside Editor::respondToChangedSelection() and we move the caret to the next work, but inside Editor::respondToChangedSelection() the spell check for the current word under caret is skipped as there is an active timer - https://trac.webkit.org/browser/trunk/Source/WebCore/editing/Editor.cpp?rev=212884#L3303. The question is how is the application supposed to refresh the spell check? In Chromium the test case works as expected. In Firefox they are renewing the spell check automatically (if spellcheck="true" is presented). The test case works in WebKit if I add a call to Editor::updateEditorUINowIfScheduled() if the timer is active, but that's not a solution as that's basically reverting the bug 129024. It also works if I'm moving the caret after 1 ms (set through setTimeout()), but that's not a solution as well. Ryosuke do you have any idea (as you are the one who introduced that change)?
A better option would be to fix bug #48411, because it would avoid the busy-loop which worked in WebKit1.