Bug 13940 – Enabling spellchecking slows down selection even when nothing is editable

• Status: VERIFIED
• Resolution: WORKSFORME
• Component: Forms

[Brett Wilson (Google)]

Frame::respondToChangedSelection asks if the current webview has spellchecking enabled and then triggers a lot of extra logic involving computing ranges, adding and removing markers, checking words, etc. This happens even when the selection isn't over a form control that can have spellchecking.

For example, go to a relatively complex page with few form controls like Google News. Select some text in one of the blurbs and scrub the mouse around. If isContinuousSpellCheckingEnabled returns true, the selection is dramatically slower than if it returns false.

[Justin Garcia]

If the selection is not editable then all we do is [from Frame.cpp]:

if (RefPtr<Range> wordRange = newAdjacentWords.toRange())
    document()->removeMarkers(wordRange.get(), DocumentMarker::Spelling);
if (RefPtr<Range> sentenceRange = newSelectedSentence.toRange())
    document()->removeMarkers(sentenceRange.get(), DocumentMarker::Grammar);

Which will do very little work since the selections newSelected{Word, Sentence} are both empty.

And:

if (!isContinuousSpellCheckingEnabled)
    document()->removeMarkers(DocumentMarker::Spelling);
if (!isContinuousGrammarCheckingEnabled)
    document()->removeMarkers(DocumentMarker::Grammar);

Which will also do very little since there will be no markers.

I can't reproduce the slowness you describe.  Are you using the latest nightly?

[Brett Wilson (Google)]

This is fixed when I synced, the version I was using was a little older. The old version checked isContinuousSpellCheckingEnabled and did a lot of work. The latest version now checks the selection's editableness before doing the hard part.