In Camino, we're providing access to OS X's system-wide spell checking panel and require a technique to iterate progressively over misspelled words in the currently focused editor. There appears to be a problem with nsEditorSpellCheck::GetNextMisspelledWord preventing it from working correctly initially. During the first execution of nsEditorSpellCheck::GetNextMisspelledWord, instead of obtaining only the text contained in the focused editor, it operates on the entire text content of the web page and will thus return the first misspelled it finds in anywhere in flattened-down text content of the entire document. Any subsequent call to this method will have properly adjusted which text block it is checking and work as expected. nsEditorSpellCheck::GetNextMisspelledWord fundamentally utilizes mozSpellChecker::NextMisspelledWord to retrieve the next incorrectly spelled word. The actual problem stems from the nsITextServicesDocument object used by mozSpellChecker which is responsible for obtaining the current text block that should correspond to the focused editor's text content. The wrong text block is retrieved when mozSpellChecker::NextMisspelledWord calls mozSpellChecker::SetupDoc to prepare the text services document's position, which results in the incorrect text block returned to NextMisspelledWord when it calls mTsDoc->GetCurrentTextBlock(&str). This can be fixed by supplying a different parameter when setting up the nsITextServicesDocument used by mozSpellChecker during the initialization of nsEditorSpellCheck: - rv = mSpellChecker->SetDocument(tsDoc, PR_TRUE); + rv = mSpellChecker->SetDocument(tsDoc, PR_FALSE); The documentation for this method: /** * Tells the spellchecker what document to check. * @param aDoc is the document to check. * @param aFromStartOfDoc If true, start check from beginning of document, * if false, start check from current cursor position. */ This fix will adjust the mFromStart member variable of mozSpellChecker and allow for proper behavior of the SetupDoc() method in that class. As the code operates currently, mFromStart would wind up equaling PR_FALSE after the first execution of SetupDoc(). I'm not sure of the implications when supplying the PR_FALSE parameter and forcing the editor spell checker to use the only editor's text from the get-go and if any negative side-effects are possible. Testing here indicates the one-line fix does enable GetNextMisspelledWord/NextMisspelledWord to behave properly without any problem. One way to reproduce: Visit a site with an input text field somewhere in the middle of the page's content, such as http://w3.org/, and type a bunch of incorrectly spelled words into the "Search W3C" text field. Finally, move the carat to the beginning of the line. Now in code, obtain the inline and then editor spell checker of the current editor and call its GetNextMisspelledWord method, which defers this task to nsISpellChecker::NextMisspelledWord. During the first execution of NextMisspelledWord, instead of obtaining only the text entered into the focused editor, it operates on the entire text content of the web page. Each word is then processed one-by-one in the order it appears in the page source and checked for correctness. The iteration stops when a misspelled word is found. So, on w3.org, this means all text content (beginning with: "Leading the Web to Its Full Potential...") is scanned and checked until the word "Amaya" (further down the left hand side) is reached. Execution is stopped at "Amaya" since it is the first misspelled word discovered on the entire page. Checking "Amaya", however, should not even happen since we started the process by invoking nsIEditorSpellCheck::GetNextMisspelledWord on the focused editor, not the entire document. Interestingly, any subsequent call to NextMisspelledWord will correctly operate on only the text entered into the editor. This is because the nsITextServicesDocument is now aware of the focused editor's location and knows how to return only the relevant text block to the spell checker. So, to the best of my knowledge, this is in fact an actual bug with nsEditorSpellCheck. Let me know if any further details are required to examine and correct this behavior.