Firefox inline spellchecker should not call suggestion generation automatically for misspelled words

RESOLVED INVALID

Status

()

Core
Spelling checker
RESOLVED INVALID
11 years ago
11 years ago

People

(Reporter: Mehmet D. AKIN, Assigned: Scott MacGregor)

Tracking

({perf})

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; tr-TR; rv:1.8.1.3) Gecko/20070321 Pardus/2007 Firefox/2.0.0.3
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; tr-TR; rv:1.8.1.3) Gecko/20070321 Pardus/2007 Firefox/2.0.0.3

We have implemented a Turkish spell checker for Firefox. We have seen an artifact causing performance problems. 

Currently Firefox tries to generate for all misspelled words automatically. Since suggestion generation is order of magnitude slower than spell checking, for documents with many errors (or documents with different languages) hogs the CPU, slows down Firefox.

Expected behavior for suggestion generation is to do it only on user interaction, meaning, firefox should generate suggestions only when user right clicks on the misspelled words.


Reproducible: Always
(Reporter)

Updated

11 years ago
Keywords: perf

Updated

11 years ago
Assignee: nobody → mscott
Component: General → Spelling checker
Product: Firefox → Core
QA Contact: general → spelling-checker
(Reporter)

Comment 1

11 years ago
After the landing of hunspell, any news on this bug? sorry for the spam.. 

Comment 2

11 years ago
Are you sure about your bug report? Can you reproduce it using the regular spellchecker? mozInlineSpellChecker::DoSpellCheck (in extensions/spellcheck/src/mozInlineSpellChecker.cpp) calls nsIEditorSpellCheck::CheckCurrentWordNoSuggest, and I don't see any other calls. Perhaps is your implementation treating CheckCurrentWordNoSuggest and CheckCurrentWord the same?

If you still think you're seeing this problem, can you post a stack using the regular spellchecking service of the suggestions being generated without user action?

Thanks.
(Reporter)

Comment 3

11 years ago
Thanks Brett, it turned out that this was a bug in our code.
 
Closing as invalid. 
Status: UNCONFIRMED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.