370346 - nsEditorSpellCheck::GetNextMisspelledWord should not check or return text outside the focused editor

Status: RESOLVED WORKSFORME

(Core :: Spelling checker, defect)

Description

[Sean Murphy]

Attachment: testcase

Iterating progressively through the misspelled words in an editor via nsEditorSpellCheck::GetNextMisspelledWord() results in erratic behavior after the final misspelled word has been reached.

The search for misspelled words is not contained to only the text found in the editor.  After reaching the last misspelled word the find will not wrap around to the beginning of the editor's text and instead jump to the next incorrect word found elsewhere in the page content.  Since we're asking the editor spell checker for the next word, proceeding out into the document text doesn't seem like the correct behavior.

The main culprit is actually mozSpellChecker::NextMisspelledWord() since nsEditorSpellCheck defers most of its responsibility to that method.  There are two different behaviors which I have observed GetNextMisspelledWord/NextMisspelledWord to exhibit:

After the final misspelled word in an <input type="text" /> field is reached, subsequent calls made to GetNextMisspelledWord will, as described above, move out into the document and return the next incorrectly spelled word it can find.  There's really no obvious way to determine if the word returned by this method was from the text field or just an irrelevant word external to the editor in concern.

Another situation again involves a call made to GetNextMisspelledWord after the final misspelled word has just been reached, but this time in a <textarea>.  The execution of the method will now actually wrap around in the contained editor and return the first misspelled word starting from the beginning of the <textarea>.  This behavior seems much more appropriate, but there's still one problem in that the selection fails to update.  The final misspelled word (the one found prior to this latest search) still represents the active selection in the editor.  The word returned by the method is not equal to the editor's nsISelection.

I've created a testcase to help reproduce and further test what I've detailed here.  It's a simple html page containing the two form elements mentioned above and some text external to the form.

So, using that file and watching the variable returned by nsEditorSpellCheck::GetNextMisspelledWord(), here's a way to reproduce each case:

<input> Case: Position the carat in the <input> field somewhere before "tthe" and call GetNextMisspelledWord on the editor's nsIEditorSpellCheck.  After the first call, "tthe" will be selected.  Call GetNextMisspelledWord again and you'll see "tthe" still retains the selection but "speelling" is now the returned word.  This new return value is outside of the <input> field at the bottom of the page.

<textarea> Case: In the <textarea>, calling GetNextMisspelledWord after the word "selectionn" was found returns "texxt", meaning it has wrapped around to the beginning.  Notice however that the selection hasn't been updated accordingly.

When concerning the context of a focused editor, it would be more beneficial if GetNextMisspelledWord's search would be contained to only the text block of this editor.  At minimum, I think returning some value to indicate the end has been reached would be more suitable - returning a useless word in the page content is almost indistinguishable from cases which return a word in the editor's text content.  For a more advantageous approach, the finding could wrap around and then start from the beginning of the editor's text.

Comment 1

[Jens Stutte [:jstutte]]

The testcase seems to work correctly these days.