The editor needs a mechanism that will allow us to do realtime spellchecking. (Spellchecking as you type.)

*** Bug 60310 has been marked as a duplicate of this bug. ***

moving to future

Not in preview mode.

*** Bug 6795 has been marked as a duplicate of this bug. ***

removing myself from the cc list

*** Bug 181888 has been marked as a duplicate of this bug. ***

taking

Dear all, I strongly recommend having a feature of spell checking. I don't mind if it works while typing or before sending, but there should be this features. Especially if you go to use Mozilla in a business environment, you have to have it. And you have to have it with all languages ( I need it with English and German). Cheers - gl

I'd be interested in energising this bug, but don't quite know which way to go. Here is a very quickly hashed together start ... The Task -------- In the editor (and the mail/news compose version), when typing and <SPACE> is hit, traverse back and grab the last typed word. It is straightforward after that I think because you can just hand the word off to IEditorSpellCheck:CheckCurrentWord. The Possible Solution --------------------- 1) Hook up another function (passing event) to the <editor> onkeypress handler. 2) Sniff out SPACE ... do nothing for all other chars typed: if (event.keyCode == event.DOM_VK_SPACE) { // get the word } 3) Use one of the DOM Range interfaces to get the word. Which one, I am not sure (nsIDOMRange ...). Or use the editor document interface and adapt the code in editor.js/EditorSetSelectionFromOffsets. But I need to get the ranges first. Thoughts and some more informed analysis would be appreciated!

*** Bug 229357 has been marked as a duplicate of this bug. ***

It is not as easy as comment 9 suggests. pasting text needs to work, moving the cursor out of a word should trigger the word to get checked, loading a document should check the entire doc etc. What i think is needed is to listen for all changes of the document. Then all words that haven't been checked or are modified need to get checked. Except the word that is currently being typed. That would be the word with the cursor on it. Tasks: - split the document into words (where te<b>se</b> is a word, te<br>st are two) - remember if a word has been checked - find out if a word is changed - listen to all changes (load, paste, cursor moves, keys, more?) - Doing all this in the background. Checking a large loaded document can take some time. - UI (styling, context menu, prefs) - non-sucky spellcheck api's

There are some guy who actually has made a working extension of the realtime spellchecking mechanism. http://forums.mozillazine.org/viewtopic.php?p=500923#500923

A counter-argument, and a possible way of keeping both sides happy... I don't have any problems with the idea of a real-time spelling checker *extension*, but I would hate to see it in the core build. I really like the idea of an ultra-fast, slimline mail client, and spelling checkers are definitely included in my definition of "bloat". They don't catch common word substitutions (e.g. "their" versus "there", "hear" versus "here", etc.), there are issues with regional spelling differences, and they are hopeless when you use a lot of industry-specific terminology. But the biggest problem with real-time spelling checkers is the amount of extra processing required. Far too many mail clients don't keep up with fast typing anyway, or don't respond quickly enough when you apply or adjust formatting: having them perform "unnecessary extras" makes them unbearable and unuseable. * Not everybody has a nice, powerful computer. * Some people who do have nice computers run a large number of applications concurrently, and individual application performance is therefore degraded. * People might like to use the same, familiar mail client wherever they are, regardless of how good or bad the hardware at those various locations is. * Even in corporate environments, spending on computer hardware and software has been way down for years. You can't automatically assume corporate users have access to up-to-date computers. (In my case, I've got the nice computers at home, and the nasty ones at work!) However, if at the general release stage (rather than technology preview) features of this kind ares IMPLEMENTED as extensions but PRESENTED as "standard" options, both points of view ("do everything" versus "lean and mean") should be able to be satisfied. Off the top off my head, I envisage something like the following: * The downloadable install set could place a bundle of popular extensions into an "available extensions" subdirectory under the application's home directory. * Some sort of file naming convention or a standard internal content element would allow a user-friendly name and/or description to be extracted from the individual extension files *without* installing them. * In Thunderbird's Options screen, there would be a section that basically listed the user-friendly name/description of everything in the "available extensions" subdirectory, each with an adjacent checkbox. The checkboxes would both display the status of each "feature" (i.e. extension), and enable the user to activate or deactivate them: - To activate a feature, the user would tick the checkbox, which would install and enable it. - To deactivate a feature, the user would untick the checkbox, which would disable and uninstall it. You'd actually probably want to store the initial state of each feature, and then do your installing and enabling (or disabling and uninstalling) when the user chose OK to accept their option changes. This would be more efficient, and more helpful for a user friendliness improvement mentioned below. * To access the settings that some extensions have, you could either have a button adjacent to each extension's name/description, or a single button outside the list of features/extensions which when clicked displayed the settings for the feature/extension selected in the list. Either way, the button(s) would be disabled for "features" that weren't activated, and features that didn't have any settings. This approach wouldn't handle the extension state of installed but disabled, but personally I think it's too fine a distinction for the typical end user to be bothered about anyway. (It certainly is for much of the audience I develop software for!) The main resulting problem is the need to exit and restart the application after changing some of these "features", when you wouldn't if you were simply enabling and disabling installed extensions. So you'd be faced with a useability trade-off decision. In my area it seems that it's generally the more technology-savvy users that look for and fiddle with options, so the need to exit and restart might not be too big a problem. But it could probably also be made more user-friendly anyway. For example, instead of giving you multiple restart warning pop-ups for each feature/extension changed, there could be a single warning pop-up when you used OK to accept option changes (along the lines of "Note: Some of the changes you made will not take effect until you exit and restart Thunderbird").

*** Bug 242675 has been marked as a duplicate of this bug. ***

Most users have a powerfull enoguh computer. For most users, spellcheck is nice. So just an option (pref, menu, whatever) to turn it off will do.

*** Bug 245568 has been marked as a duplicate of this bug. ***

taking, for now until the person who has a patch takes over.

I remember rods sending me an email with lots of situations to handle for realtime spellchecking. I'll see if I can dig through my mail archive to find it. Also I believe he also started implementing realtime spellchecking ... for HTML, not just plaintext, but I think it was all tangled up with the "spellchecker re-write" code he posted to one of the open spellchecker bugs.

If rods has some skills valuable for the realtime spellchecking mechanism he should really try to help out Ausdilecce since he almost have a fully functional extension availible. More info on that subject exist in the mozillazine-forum http://forums.mozillazine.org/viewtopic.php?t=63506&postdays=0&postorder=asc&postsperpage=15&start=0 and the extension can be downloaded from http://www.supportware.net/mozilla/#ext8. It seems like a better idea that rods check it out before starting to work on an own solution.

Please excuse me in advance if my question does not make any technical sense (I am not familiar with the mozilla code), but wouldn't it be possible to simply use the gtkspell library? (http://gtkspell.sourceforge.net) I use logjam (http://logjam.danga.com), which uses it, and it's a real wonder.

We already have a Mozilla implementation that is based on GTKSpell functionality. We don't use GTKSpell but the functionality is the same. We hope to get a patch for this code posted to this bug soon.

*** Bug 252562 has been marked as a duplicate of this bug. ***

I see this as a very important feature - one that my mom says makes Thunderbird feel inferior to old Eudora Pro. Perhaps some as-you-type spell checking code can be borrowed from KMail (http://kmail.kde.org/)? They do a nice job of highlighting words (not underlining) that are misspelled and providing suggestions upon a right-click.

This we hope to contribute to Mozilla soon. It has been implemented for some time now for Lindows and is available in their next distro to be release in August.

Just to echo the KMail comment. I actually use KMail now, over Thunderbird for two reasons: 1) it has spell-as-you-go 2) its taskbar icon notifies you of *how many* new email you have, which is incredibly handy. I'd go back to Thunderbird if the spell-as-you-go was implemented, which is why I continue to track its progress. Added to this, a friend of mine who is having problems with Outlook finally heard the gospel and tried Thunderbird last week. He ditched it within a day only because of the lack of spell-as-you-go. So, hopefully it will be implemented soon as it's a definite "must have" feature for many people.

Advocacy comments are not usefull at all (except to drive away developers). Nobody is denying this would be a cool feature. Code from other projects can't just be intergrated, because other toolkits are used, other licenses and maybe even other languages.

(In reply to comment #24) > Created an attachment (id=154200) > Screen Shot > > This we hope to contribute to Mozilla soon. It has been implemented for some > time now for Lindows and is available in their next distro to be release in > August. That's great news! If you guys already have this implemented, then doesnt this basically solve the bug? Of course, i still dont know whether mozilla would accept the code, what with licensing issues, etc. I hope they do, and i must say, the screenshot looks good :-)

FWIW, there is already an extension that addresses this, written by AusDilecce at the following URL: http://www.supportware.net/mozilla/ It's very much a work-in-progress, but in the spirit of not having effort duplicated, I thought I'd pass it along... I haven't used this extensively enough to have any real comments on how well it works, so I can neither endorse it nor pan it.... Erick

It would be very nice to check spelling as I type.

As I recall Daniel Glazman has been doing this for Nvu... perhaps after 0.50... he'll donate some of that code for recycling purposes ;-)

(In reply to comment #30) > As I recall Daniel Glazman has been doing this for Nvu... perhaps after 0.50... > he'll donate some of that code for recycling purposes ;-) I did nothing. The code is Neil Deakin's. I just added a few lines of chrome to make it work in Nvu and recently based the red underline color of the mispelled words on a pref. All the credit for this feature should go to Neil. He is working on a patch that will be attached here soon. Stay tuned.

This is the big patch for inline spellchecking as it appears in Linspire Internet Suite 1.6, ported to the Mozilla 1.8 trunk. It's a big patch and touches numerous modules, though mostly editor, extensions/spellcheck, text frame drawing and selection. I could provide a split up version if desired. It implements the red underline under mispelled words for things that use the editor widget. Currently enabled for message compose (plaintext and html), page composer and html multi-line textareas.

Neil - thank you very very much. I just tried out the patch and it works really well and here comes the but... I found that changing the pref in about:config while there was a textarea in another tab caused a crash. I was able to reproduce it by hitting refresh a couple of times with the tab with the textarea active, switching to the tab with about:config open, and toggling the pref. ns_if_addref(nsPresContext * 0xdddddddd) line 114 + 9 bytes nsTypedSelection::GetPresContext(nsPresContext * * 0x0012d760) line 6585 + 24 bytes nsTypedSelection::RemoveAllRanges(nsTypedSelection * const 0x032f9d38) line 5546 + 32 bytes mozRealTimeSpell::EnableRealTimeSpell(mozRealTimeSpell * const 0x032fadc8, int 0x00000000) line 217 mozRealTimeSpell::Observe(mozRealTimeSpell * const 0x032fadd0, nsISupports * 0x00b8e080, const char * 0x011eb108, const unsigned short * 0x0012d908) line 96 + 20 bytes Also, I expect that you already know that the word breaker stops on apostrophes and then underlines the first half of contractions as misspelled. Besides that, all I can say is wow and thank you.

This code was implemented on the 1.6 Branch. I can't reproduce the crasher on the los build of Mozilla. So it must have something to do with the port to 1.8. Same goes for the contraction issue. Contractions work fine on 1.6 los build. I doubt it has anything to do with the fact that we are using Aspell as our default spelling engine.

Comment on attachment 164452 [details] [diff] [review] Inline spellchecking patch from Linspire >+ if (!(editorFlags & nsIPlaintextEditor::eEditorSingleLineMask) && >+ !(editorFlags & nsIPlaintextEditor::eEditorReadonlyMask) && >+ !(editorFlags & nsIPlaintextEditor::eEditorDisabledMask)){ !(editorFlags & (nsIPlaintextEditor::eEditorSingleLineMask | nsIPlaintextEditor::eEditorReadonlyMask | nsIPlaintextEditor::eEditorDisabledMask))) { >+ nsCOMPtr<mozIRealTimeSpell> rts; Not used. >+ mEditor->EnableRealTimeSpell(PR_TRUE,NULL); >+ } >+ else if (enableRTS == 0){ >+ mEditor->EnableRealTimeSpell(PR_FALSE,NULL); >+ } Is multiply enabling/disabling real time spell that expensive? > nsAutoString mozQuote; > if (NS_SUCCEEDED(content->GetAttr(kNameSpaceID_None, mMozQuoteAtom, mozQuote))) { > *_retval = mozQuote.LowerCaseEqualsLiteral("true"); > } >+ >+ nsAutoString className; >+ if (NS_SUCCEEDED(content->GetAttr(kNameSpaceID_None, mClassAtom, className))) { >+ *_retval = className.EqualsIgnoreCase("moz-signature"); >+ } else in between? I suppose a quote is unlikely to have a class name... >- >- if (NS_FAILED(rulesRes)) return rulesRes; >- return res; >+ >+ return rulesRes; This doesn't actually mean the same thing... >+// Spellchecker code has this. See bug 211343 >+#ifdef XP_MAC >+#define IS_NBSP_CHAR(c) (((unsigned char)0xca)==(c)) >+#else >+#define IS_NBSP_CHAR(c) (((unsigned char)0xa0)==(c)) >+#endif Although a bug comment suggest it doesn't apply to Unicode strings... > if (aTopic == "obs_documentCreated") > { > var editor = GetCurrentEditor(); >- if (editor && GetCurrentCommandManager() == aSubject) >+ if (editor && GetCurrentCommandManager() == aSubject){ > gMsgCompose.initEditor(editor, window.content); >+ RealTimeSpell.Init(editor, true); >+ RealTimeSpell.checkDocument(window.content.document); >+ } > } How likely is it that new documents need spellchecking? >+ if (!this.editorRTS) return null; JS Strict warning: function does not always return a value >+ var docelem = doc.body; >+ range.setStartBefore(docelem); >+ range.setEnd(docelem,docelem.childNodes.length); range.selectNodeContents(doc.body); >+ if (!suggestion.length) break; if (!suggestion) would suffice. >+ var editor = this.target.editor; More JS strict warnings (unless you only ever context click textareas)... >+ prefBranch->GetBoolPref(NS_LossyConvertUTF16toASCII(aData).get(), &enable); Might as well use PREF_ENABLEREALTIMESPELL + res = EnableRealTimeSpell(enable); So, if you change the pref, suddenly everything gets spellchecked?

Timeless->Josh I read some of your odious comments in the patch. I must say they exemplify precisely why someone would *never* want to contribute code to Mozilla. I think this type of attitude is poisonous, anti-productive, repellent, and nonconstructive. If you have a problem with the patch a. offer some constructive comments/collaboration b. fix it yourself c. remove your email from this bug Otherwise no one wants to hear this type of drivel.

I don't understand. Are you referring to the review in attachment 164987 [details]? It looks entirely relevant and appropriately polite, with the possible exception of the reference to 'sucky code' which AFAICT is explicitly referring to the old code being moved/touched, not the new contributed code (and is also a valid point to bring up in a review, since any touched lines of code, even rearragements and whitespace changes, will have 'cvs blame' thenceforth point to whoever checks in the patch).

*** Bug 268676 has been marked as a duplicate of this bug. ***

Found this extension for TB, haven'nt tested it (!): http://kb.mozillazine.org/index.phtml?title=Thunderbird_:_FAQs:_Inline_Spell http://www.supportware.net/mozilla/#ext8 I had filled a bug specifically for TB (see 268676 ) but it was marked a dupe of this one.

(see next comment)

I have tested the extension mentioned in my last 2 comments with the following results: - Windows XP, TB 0.9 fr-FR (release from Mozilla Europe), english and french dictionaries, works for me, but requires existing c:\AutoCorrect.txt example file to be present (separate download from same site) - Windows 98, TB 0.9 fr-FR (release from Mozilla Europe), english or french dictionaries, works for me.

Sorry - last comment should have been "Win98 - does not wok for me"

the extension is not near as stable and fast as the solution from linspire is.

I'll use it fo rthe next few days an report back. Unfortunately I don't use the Mozilla suite and I don't see this making it to TB anytime soon (meaning in time for 1.0), so I'll take what's available and WFM.

(In reply to comment #44) > the extension is not near as stable and fast as the solution from linspire is. Correct. Neil's code is included in Nvu 0.50, and we estimate the number of users of Nvu 0.50 to 150,000. We have not a single negative feedback, I repeat *not a single* negative feedback about this feature in the *thousands* of emails we received since Nvu 0.50 release. We only got one comment that requires an answer : the underlining is red is not "accessible" to color-blind people and this should be configurable. I agree and it's something I am going to add to Nvu.

(In reply to comment #46) > > Correct. Neil's code is included in Nvu 0.50, and we estimate the number of > users of Nvu 0.50 to 150,000. We have not a single negative feedback, I repeat > *not a single* negative feedback about this feature in the *thousands* of emails > we received since Nvu 0.50 release. > One by blog ;-) http://robert.accettura.com/archives/2004/10/12/nvu-050-released/ I still think there needs to be more of a delay. Just try typing "welcome to my website" in NVU. The red lin flashes during writing welcome, and website. IMHO it shouldn't start until the word (as defined by a " " after a series of alpha characters is entered.

Daniel: Some czech user note that wavy underline (~~~~~~~) in MS Word is great. Maybe something like border-bottom:1px -moz-wavy #C00 should be solution.

I have both Nvu 0.5 and Thunderbird 0.9 with the In-Line SpellChecker v0.4.72 extension installed on my machine. I have to agree that as I use Nvu I find the flashing red line is distracting and I miss the auto-correction feature of Thurderbird extension. My machine is pretty fast so I can't comment on differences in speed between the two implementations but I can say I haven't noticed any stability issues with either. Neil's may every well be the better implementation, but I would like to see it expanded to use 1) the extension's wavy underline, 2) an option to use the extension's delayed spell-check-on-word-break, and 3) the extension's auto-correction feature.

mozilla@pottinger.ca: why did you select assigned? are you working with neil?

Maybe the devs should consider adding spellchecking as you type to the richtext/textbox widget instead. This will not only allow tb to do realtime spellchecking, but it will also allow fx and sb to do the same.

*** Bug 270960 has been marked as a duplicate of this bug. ***

The In-Line SpellChecker v0.4.72 extension is really a poor solution. It has numerous irritating bugs. And the extension does not work under TB 1.0. Probably some sort of versioning problem. I'm very disappointed that this feature did not make it into TB 1.0 proper. I had come to rely on the Mac OS X Mail.app's inline spell checker. Moving to TB has made me change the way I work and dumped me twenty years in the past where spell checking was a modal process.

Any chance to implement the inline spell checker that's built into the Mac? The other platforms should be able to use whatever spell checker their manufacture provides. That would be the best solution for all platforms.

(In reply to comment #54) > Any chance to implement the inline spell checker that's built into the Mac? The other platforms should > be able to use whatever spell checker their manufacture provides. That would be the best solution for > all platforms. Yes, I'd love to have the Grammar & Style checker on Windows, inline or not, but the one which is used by Microsoft Office. Nonetheless, is it technically and legally possible to integrate this feature? I think that I've dealt with one small, non-commercial programme (some plug-in for Far Manager, to be exact) that uses the Microsoft Office spell-checker, so it should be possible to code it one way or another. P.S. I have to admit that right now I am copying and pasting everything (including the mail) into Microsoft Word in order to make sure that everything looks okay. And I think, I am not alone in this. :-)

Can we move the discussion about what you all want to somewhere else, and concentrate on the actual patch? Complaining that an extension isn't good enough for you doesn't help geeting the patch reviewed and all.

*** Bug 267147 has been marked as a duplicate of this bug. ***

see Bug 278310 and Bug 278312 for further work

Absolutely neccesary for modern eMailing.

Comment on attachment 164452 [details] [diff] [review] Inline spellchecking patch from Linspire >Index: editor/libeditor/base/nsEditor.cpp >=================================================================== > mEditorObservers = 0; >- >+ >+ if (mRealTimeSpell){ >+ mRealTimeSpell->Destroy(); >+ mRealTimeSpell = nsnull; >+ } >+ This is a very bad thing to do. mRealTimeSpell is refcounted, and you don't know who is holding references to it outside of editor (like JS, for example). You should just release your owning reference here. If Destroy() needs to called to clean up state, then call it here, but ensure that the orphaned mRealTimeSpell object won't crash if any of its methods are called.

Doh, scratch that last comment. I see that Destroy() does not delete. I would suggest, however, that Destroy() is renamed to Cleanup() or something. It doesn't actually destroy the object.

Comment on attachment 164452 [details] [diff] [review] Inline spellchecking patch from Linspire How about we strive to look intelligent by not misspelling "misspelled"?

How is this patch coming along?

Scott used this patch as a basis for his back end work in bug 278312. Note that Thunderbird trunk builds support inline spell checking since February. Thunderbird's front end was fixed by bug 278310 and a couple of follow-ups. That was just ported to Seamonkey by bug 291799. I'm still missing inline spell check in <textarea>s though.

We don't have spellcheck in Suite's web page editor yet either.

This would be a killer feature - Konq already does it, and IE doesn't :-)

Can this patch be cleaned up, and targeted for Gecko 1.9?

The patch here is already available in cleaned up form in Gecko 1.8. The only extra piece needed for textarea spelling is the nsTextControlFrame.cpp changes and the UI changes in xpfe/communicator. The patch here doesn't include any page composer support, although it is also just UI changes similar to the browser part. I plan to provide an updated patch for inline spell in textareas for Firefox at some point.

*** Bug 305865 has been marked as a duplicate of this bug. ***

Has there been any work on inline spellcheck for textareas in firefox-1.5? This is the only bug I find. Are there any pointers to info or bugs.

Firefox 1.5 has already been released, and I assume this feature would be too big a change for the maintenance releases. It is slated to be in Firefox 2.0, though. However, if you want to get spellchecking in 1.5, check out the Aspell extension (disclaimer: I've never tried it myself). http://forums.mozillazine.org/viewtopic.php?p=1977210

See bug 302050 and its dependencies, which is fixed on trunk. It needs to be ported to the 1.8 branch for Firefox 2.0, see bug 329668.

(In reply to comment #70) > Has there been any work on inline spellcheck for textareas in firefox-1.5? This > is the only bug I find. Are there any pointers to info or bugs. Probably the best/most popular spell check extension is SpellBound which can be installed from http://spellbound.sourceforge.net/install.

Though I've been using the 'development' spellbound from http://forums.mozillazine.org/viewtopic.php?t=351130 on both Windows and Linux for months now with no issues - features in-line text area red-squiggle underlines, ctrl-left click to select alternative spellings.

Now editor has inline spellchecking (nsIInlineSpellChecker interface), textbox has it too since it has property 'editor' that returns nsIEditor interface. What about is the bug? I guess the current problem only is that textbox context menu doesn't contains items for spellchecking support (f.x. I think context menu should have item for suggested words).

This bug, about implementing inline spell in Mail Compose has been fixed for a while. Other bugs, like 338318 are about inline spellcheck in other areas.

Verified FIXED. This has, like Neil said, been in--even in SeaMonkey--for quite a while now. Build 2006-08-13-06 of SeaMonkey trunk under Windows XP.